Sensitive data · GDPR article 9
Health data your clients trust you with, kept where the rest of the CRM cannot reach it.
A gym records injuries and medication. A physiotherapist records a diagnosis. That is special-category data under the GDPR, and a CRM field is the wrong place for it. Datos sensibles is a protected store beside the CRM: encrypted, visible only to the roles you choose, signed for by the client, and logged every time anyone reads it.
The problem
Why a custom field is the wrong home for a diagnosis.
Everything that makes a CRM field useful is what makes it unsafe for health data. So this data is kept out of the CRM, rather than stored in it behind a flag that every feature would have to remember to respect.
Everyone with the CRM can read it
A custom field is visible to anyone who can open the contact. Need-to-know access is exactly what the GDPR asks for this kind of data, and a CRM field cannot give it.
It is searchable
Filters, saved views and exports work on every field. That is what makes a CRM useful, and it means anyone can pull up a list of everyone with a given diagnosis.
It travels
Assistants, automations, imports and chat histories all read CRM fields. Every new tool that reads the CRM reads the health data too, unless someone remembers to exclude it.
Nobody knows who looked
A field records its value, not who read it. When a client asks who has seen their medical history, or when to erase it, a CRM field has no answer.
How it is built
A store the rest of the system cannot see into.
Every protection sits below the screen, where a direct call to the API meets it too. Hiding a field in an interface is not security.
Watched by
Compliance
A store of its own
Sensitive data lives in separate tables that nothing else in aicroo can read: not CRM search, not views, not automations, imports or the ordinary export. No user or API key can query those tables directly; every access goes through a function that checks the permission first.
Encrypted before the database sees it
Each value is encrypted in the application server with AES-256-GCM before it is stored, and bound to its company, client and field, so a value copied onto someone else’s record will not decrypt there. The key is not in the database: backups, logs and database administrators only ever see ciphertext.
Sight is a permission you give
Reading, writing and configuring are three permissions, marked as dangerous, that you put in whichever roles need them. Someone without the permission does not see a locked section. They do not see the section at all, and cannot tell whether a client has sensitive data.
Read and written through your Mini-apps
Values are captured and shown only in the Mini-apps you build for the job, such as a client file or a measurement form, and through the REST API for a key whose role holds the permission. The app itself handles consent, export, erasure and the access log. It never displays a value.
Every read is written down
Each read, write, export and erasure is recorded in the same transaction as the access, in a hash-chained log you can verify from the settings screen. The log records who, which client, which fields and through which channel. It never records the value.
Unusual access is flagged
When one person or key reads the data of more than 50 clients in 24 hours, whoever configures the store is told, by inbox, e-mail, Teams or Slack. You set the threshold. Notices sent outside the app never name the client.
Consent, signed
Nothing is recorded until the client has signed.
Explicit consent is a document, not a checkbox. It is separate from the membership contract, each purpose is ticked on its own, and the client keeps a sealed copy.
In person, on a tablet or computer
- Staff open the client and start the signing. The device switches to client mode, and only a staff password gets it out.
- The client reads the text and ticks each purpose separately.
- They confirm their e-mail with a code sent to it, then sign by hand on the screen.
- The document is sealed with an advanced electronic signature, with the witnessing staff member, device and time recorded. The client gets a copy by e-mail.
Remotely, from a link
- Staff, or a Mini-app, request the signature. The client receives a link by e-mail.
- They verify with a code sent to their e-mail, read, tick the purposes and sign.
- The same seal and the same evidence as in person. The client gets a copy.
- Until it is signed, nothing can be recorded. A pending consent counts for nothing.
For a physiotherapist, a clinic or anyone working under professional secrecy, the basis can instead be the health professional (art. 9(2)(h)): no client signature, and the responsible professional’s name and registration number are recorded.
The GDPR, article by article
What the regulation asks, and what the product does about it.
We do not call software “GDPR compliant”. Compliance is a property of your processing, not of a tool. What we can show is the mechanism behind each obligation.
Art. 9(2)(a)
What it asks: Explicit consent to process health data.
What aicroo does: A signed consent document, with each purpose ticked separately. No value can be written for a client until it is signed.
Art. 9(2)(h)
What it asks: Or care given by a professional bound by secrecy.
What aicroo does: The professional basis, with the professional named and their registration number recorded.
Art. 7(1)
What it asks: Being able to prove the consent was given.
What aicroo does: The sealed document is kept even after the data is erased, as proof the processing was lawful while it lasted. It contains no health data.
Art. 7(3)
What it asks: Withdrawing consent as easily as giving it.
What aicroo does: Withdrawal blocks new records at once and erases everything 30 days later. The client can take an export in between. A new consent in that time cancels the erasure.
Art. 5(1)(c)
What it asks: No more data than the purpose needs.
What aicroo does: There are no predefined health fields. You define each one, or the Mini-app you publish declares it, and your impact assessment justifies it.
Art. 5(1)(e)
What it asks: Keeping data no longer than necessary.
What aicroo does: Data is erased automatically 24 months after a client’s last record (you choose between 1 and 120), even if consent was never withdrawn, with a warning 30 days before. The access log itself is kept 4 years, then deleted.
Arts. 15, 16 and 20
What it asks: Access, rectification and portability.
What aicroo does: A per-client export with the values decrypted, from the contact or through the API. A corrected value is an edit, and the edit is logged.
Art. 17
What it asks: Erasure on request.
What aicroo does: Erasing a client deletes their values and records for real, not by hiding them, after a typed confirmation. The act is logged and notified.
Art. 25
What it asks: Protection by design and by default.
What aicroo does: The store is off until a company switches it on, and no role can see it until you add the permission. Nothing that already reads the CRM can reach it.
Art. 32
What it asks: Security appropriate to the risk.
What aicroo does: Encryption per value with a key held outside the database, a permission check in the database on every access, a verifiable access log and unusual-access alerts.
Arts. 30 and 35
What it asks: A record of processing, and an impact assessment.
What aicroo does: Templates for both come with the feature, together with a starting consent text. They are drafts for your own processing, which is yours to complete.
Who is responsible for what
You are the controller. We give you the means, and the evidence.
Under the GDPR your company is the controller: you decide why the data is collected, which fields exist, who may see them and on what legal basis. aicroo is the processor, and switching the store on records your acceptance of a special-category addendum to the processing agreement. Software cannot make processing lawful on its own. It can make the lawful path the only one available, and leave evidence you can show. The legal readings here, such as which basis applies and whether an advanced signature is enough evidence of explicit consent, are the ones we built to. Have your data protection officer or counsel confirm them for your case.
What it will not do
Some doors are closed by design.
Never sent to an AI model
Not a value, not a count, not a paraphrase. The assistant and MCP have no function that reaches the store, and a test fails the build if one ever appears.
Never searchable
There is no filter, sort or search on a sensitive value, by design. Nobody can list the clients who have a given condition.
Never a biometric
A hand-drawn signature is kept as the final image only. Stroke timing and pressure are not captured, because that would itself be special-category data.
Watched, not filed
The Compliance AI employee keeps the store honest.
It sees counts, never values, and it writes no narrative about this data. It raises what needs a person’s attention.
Watched by
Compliance
- Clients whose consent was withdrawn and whose data is waiting for its erasure date.
- Remote consents requested more than 7 days ago and still unsigned, so nothing can be recorded for those clients.
- Clients whose retention limit falls within 30 days, or has passed without the automatic erasure running.
- Archived contacts that still hold sensitive data.
- An access log whose chain no longer verifies. That is an incident, and it is raised as one.
See a consent signed, a value recorded, and the trail it leaves.
Bring whoever handles data protection for you. We will switch the store on, sign a consent on a tablet, record a measurement from a Mini-app, and open the access log together.