What Article 9 asks for when your systems hold special category data
If your systems hold health, biometric, genetic or other special category data, the starting point is a prohibition: processing is not allowed unless one of the Article 9(2) exceptions applies. The exceptions are specific, and finding that a field contains sensitive data does not by itself make any use of it lawful. Article 9(1) covers data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, along with genetic data, biometric data used to identify a person, health data, and data on sex life or sexual orientation. Article 9(2) lists ten exceptions, including explicit consent, employment and social protection law, vital interests, legal claims, health and social care, and public health. Member States may add conditions or limitations for genetic, biometric and health data under Article 9(4), so the answer for a given system can depend on the country where the data subjects are located and where the controller operates.
The legal test is often the easy part. The harder work is finding the data. Special category values rarely sit in one tidy column. They appear in free-text notes, support tickets, uploaded documents, form fields that were never meant to collect health details, application logs that record request payloads, analytics events, exports, and backups taken before anyone classified the content. Ask engineering to search databases, object stores, log pipelines and backup catalogs for the categories you hold, and record which systems were searched and how. Treat a search that returns nothing as a result to document, not a proof of absence, because unstructured content is hard to match with patterns alone.
Once you know where the data sits, decide for each location whether an exception applies and who relies on it. Record the chosen exception next to the processing purpose in your records of processing, because the exception determines the safeguards you must show. Where the exception is explicit consent, confirm that the consent mechanism is capturable and withdrawable in the system that stores the data. Where processing is large-scale, expect a DPIA under Article 35(3)(b) and check whether a DPO is required under Article 37(1)(c). If the data feeds automated decisions, Article 22(4) limits their use on special categories, so confirm with your legal team which exception and safeguards apply before any model or rule goes live. Ask your counsel to confirm the national conditions that apply in each country where you operate.
Which systems, data and teams fall under Article 9 scoping
Article 9 scope is rarely set by a single database table. It spreads across inferred fields, free text, attachments, third-party feeds, and the people and processors who can reach them. The cards below name the scoping decisions that change the work, so the DPIA, records and access controls cover what the data actually reveals.
Fields that reveal data by inference
A field does not need to be labelled health or religion to fall under Article 9(1). A prescription pharmacy name, a dietary flag on an event booking, or a union dues deduction in payroll can reveal a special category by inference. Treat any field that lets a reader conclude a protected attribute as in scope, then document which fields were reviewed and why others were excluded. Ask data owners to list derived and calculated fields, not only the original inputs.
Free text and comment fields
Case notes, support tickets, HR comments and free-text descriptions are where special category data appears without a schema telling anyone. Scoping should assume that any open text field in a system handling health, employment or customer welfare may contain Article 9 data. Decide whether these fields get the same access, retention and logging controls as structured records, or whether text is minimized or redacted at intake. Confirm this with a sample review of real entries, not only the form design.
Attachments and scanned documents
Uploaded medical certificates, identity documents, fit notes and signed forms carry special category data inside files that search and schema reviews never open. Nextcloud's server-side encryption protects file contents at rest but does not encrypt file names or folder structure, so a folder called with a diagnosis or union name remains visible to anyone with metadata access. Inventory where attachments are stored, who can download them, and whether file and folder names are themselves sensitive.
Data received from third parties
Referral letters, insurer claims, screening vendor results and biometric check outputs can arrive already classified as special category data. The controller that receives this data takes on Article 9 obligations even when another party collected it, so the scope must start at the point of intake. Record the source, the lawful exception relied on, and whether the sending party has confirmed a basis. Feeds that arrive by API or bulk import often bypass manual review, so check them against the same classification rules.
Teams and roles with access
Every team that can read, export or change special category data widens the scope, including support, analytics, engineering, backup administrators and finance staff who reconcile invoices from health providers. Scope should list roles, not only systems, and the access review should check whether each role still needs the data. midPoint access certification campaigns let designated reviewers keep, change or revoke role assignments within a set timeframe, which helps show that access to sensitive data is reviewed.
Processors, sub-processors and key management
Hosting providers, managed support firms, backup services and key management tools that can decrypt special category data are part of the processing chain. Confirm each processor's contract covers Article 9 data, that sub-processors are listed, and that remote support sessions are logged. Key management matters here too: OpenBao's transit secrets engine can encrypt and decrypt application data without storing it, with versioned keys and rotation, but the operators who manage its policies still sit inside the scope. Ask each processor which of its staff can reach plaintext.
Choosing an Article 9(2) exception and recording it per purpose
Each processing purpose that involves special category data needs its own Article 9(2) exception, and the controller must choose and record that exception before the processing starts. Article 9(1) prohibits the processing by default, so an exception is a positive decision, not a fallback. Do not treat any exception as a default, and do not reuse one exception across purposes because it happens to fit the first use case. A clinic booking appointments, a clinic running occupational health checks for staff and a clinic sharing records for legal claims are three purposes, and each may rest on a different exception, or none may apply to one of them. Ask the data protection lead to write down, per purpose, the exception relied on, the data elements involved and the person who approved the choice.
The chosen exception shapes the technical design. If it is explicit consent under Article 9(2)(a), the system needs consent records that show what was agreed, when, through which interface and in which version of the notice, and withdrawal must stop the processing for that purpose. If it is employment and social protection law under Article 9(2)(b), access controls must follow the legal authority, and HR staff should not see health data beyond what that authority permits. If it is health and social care under Article 9(2)(h), access should be limited to professionals bound by secrecy obligations, and the retention rule for that purpose should match the sector rule. Where the exception rests on legal claims under Article 9(2)(f), retention should end when the claim is resolved, not when a generic schedule says so. Record the exception as a field in the processing register, and make sure logs and backups inherit the same classification.
Article 9(4) allows Member States to maintain or introduce further conditions and limitations for genetic, biometric and health data. An exception that works under EU-level rules may still carry extra national conditions, so the reader should confirm the requirements of each country where the data is processed and where the data subjects live, and have legal counsel confirm them in writing. Build that check into the DPIA and into the approval record for each purpose, and plan for a review when a national rule changes. Costs here are mostly internal legal and records work, which recurs whenever a new purpose or jurisdiction is added. Ask any outside adviser to state in the written scope which jurisdictions and purposes the review covers.
How an assessor tests Article 9 compliance
This table walks through the steps an assessor typically takes when testing special category processing, from the data inventory to automated decision controls. Read each row as a test step with the evidence it asks for and the findings that most often appear. The main takeaway is that an assessor looks for proof that each sensitive data flow has a documented exception and that the system behaves as the records say.
| Test step | What the assessor checks | Evidence requested | Common findings |
|---|---|---|---|
| Confirm the data inventory | Whether special category fields (health, biometric, genetic, union membership and others under Article 9(1)) are identified in schemas, forms, files and feeds | Data inventory or record of processing entries flagging special categories, schema extracts, data flow diagrams | Sensitive fields inferred from free text or attachments that were never added to the inventory |
| Check the recorded Article 9(2) exception | That each processing purpose involving special categories names a specific Article 9(2) exception and any extra Member State condition under Article 9(4) | Records of processing with the exception stated per purpose, consent records where explicit consent is relied on, legal analysis for other exceptions | Exceptions left blank, a general statement that consent was obtained, or an exception that does not match the purpose |
| Sample system configuration | Whether technical settings support the restricted processing, such as segregated stores, encryption and limited integrations for sensitive data | Configuration exports, encryption settings, storage locations, screenshots of relevant admin panels, change records | Sensitive data copied into general reporting databases or exports without the same controls |
| Sample access rights | Whether only roles with a documented need can view or export special category data, and whether reviews happen | Role assignments for systems holding sensitive data, access review results, approval records for elevated access | Broad group access inherited from general staff roles, stale accounts retained after a role change |
| Check for sensitive data in logs and telemetry | Whether application logs, error traces, analytics events and support tickets avoid storing special category values | Log samples, logging configuration, redaction or masking rules, retention settings for log stores | Diagnostic logs capturing health or biometric values, or request bodies stored in monitoring tools |
| Review DPIA and DPO triggers | Whether large-scale special category processing has a DPIA under Article 35(3)(b) and whether a DPO was designated where required under Article 37(1)(c) | Completed DPIAs with dates and review history, DPO appointment record, reasoning where a DPO was judged not required | No DPIA for a new sensitive data feature, DPIA not updated after a system change, no documented reasoning for skipping a DPO |
| Check the Article 30(5) record-keeping position | Whether the organization kept processing records even though it is under 250 employees, because special category processing removes that exemption | Current records of processing covering each special category activity | Small organizations relying on the exemption while processing health or biometric data |
| Test automated decision controls under Article 22 | Whether decisions based on special categories are either excluded or rest on explicit consent or substantial public interest with safeguards | Decision logic documentation, model or rule inputs list, consent evidence, human review procedure, safeguard descriptions | Scoring or eligibility rules that use health or other sensitive attributes without a recorded basis or review path |
How to implement Article 9 controls in sequence
This sequence moves an organization from knowing where special category data sits to proving, for each purpose, which Article 9(2) exception applies and how the data is protected. Each step produces a record that the next step depends on, so the outputs can be reviewed by the privacy team, security engineers and an independent assessor.
Discover special category fields and datasets
Start by finding every place special category data enters or is created in your systems. Working with data owners, product teams and HR or clinical leads, list the fields, documents, logs, free-text notes and derived attributes that can reveal health, biometric, genetic, religious, political, union or sexual orientation information. Include data inferred from other fields and data received from customers or partners. The output is a field inventory that names the system, owner, data subjects and the element that makes it special category. The step is complete when data owners have signed off the inventory and someone has checked it against sample database schemas and storage buckets.
Map each purpose to an Article 9(2) exception
For every processing purpose that touches an inventoried field, record the Article 9(1) category involved and the single Article 9(2) exception you rely on, such as explicit consent, employment and social protection law, health and social care, or legal claims. Note any further national conditions that apply under Article 9(4) for genetic, biometric or health data in the countries where you operate. Legal or privacy counsel should review entries where the exception is not obvious. The output is an exception register linking each purpose to its category, exception, legal reviewer and date of review. The step is complete when no purpose touching special category data lacks an exception.
Restrict access and encrypt the data
Apply the technical measures that match the register, starting with role-based access limited to the people who need each purpose, and separate storage for special category fields where the architecture allows it. Encrypt the data at rest and in transit, and keep encryption keys in a managed secrets service rather than in application code. Self-hosted platforms can support this: Nextcloud server-side encryption protects file contents at rest but does not encrypt file names or folder structure, and the OpenBao transit secrets engine can encrypt application fields with versioned keys that support rotation. Confirm the behavior of each product in your own environment. The output is an access matrix and an encryption design. The step is complete when test accounts outside the approved roles cannot read the protected fields.
Update the record of processing
Update the Article 30 record of processing for each purpose so it lists the special category data, the Article 9(2) exception, the recipients, the retention period and the security measures. Many organizations assume the record-keeping exemption applies to small organizations, but processing special categories removes that exemption, so the record is required even below the employee threshold. Cross-check each entry against the field inventory and the access matrix. The output is a current record of processing with version history. The step is complete when every special category field in the inventory maps to at least one entry.
Run the DPIA and the DPO check
Determine whether the processing is large-scale special category processing, which requires a data protection impact assessment under Article 35(3)(b). Where it is, document the necessity, proportionality, risks to individuals and mitigations, and involve the data protection officer. Separately, check whether special category data processing is a core activity, which under Article 37(1)(c) requires a DPO to be designated. Record the decision even when the answer is no. The output is a DPIA report or a documented screening decision, plus a DPO designation or justification. The step is complete when the decision is approved by the accountable manager and the DPO has reviewed it.
Review automated decisions using special categories
Identify any automated decision or profiling that uses special category data. Under Article 22(4), such decisions may not rely on these categories unless explicit consent or substantial public interest applies, and suitable safeguards are in place. Review model inputs, scoring rules and workflow triggers, and confirm that special category attributes are excluded where no exception covers them, including through proxy fields that could reveal the same information. The output is a decision register with inputs, legal basis for each automated decision and the human review or appeal route. The step is complete when each automated process has been tested with the special category inputs removed and the results are documented.
Confirm evidence for the assessor
Assemble the outputs from the previous steps into one evidence folder: the field inventory, exception register, access matrix, encryption design, record of processing extract, DPIA or screening decision, and the automated decision register. Ask your legal team to confirm that the evidence matches the current processing. An independent auditor or supervisory authority will judge whether the controls are adequate; DeployOpen can prepare systems and documentation for that review but does not issue reports or certificates. The output is a dated evidence pack with an owner for each item. The step is complete when each item can be traced to a live system or a signed-off document.
How special category processing changes DPIAs, DPOs and records
Processing special category data at scale changes three governance duties at once: a data protection impact assessment is required, a data protection officer must be designated where this processing is a core activity, and the small-organization exemption from keeping records of processing no longer applies. Article 35(3)(b) makes the DPIA mandatory for large-scale processing of special categories, so the trigger is the scale and nature of the processing rather than the size of the company. Article 37(1)(c) requires a DPO only where large-scale special category processing is a core activity, which means the organization must decide honestly whether the service it sells or runs depends on that data. Article 30(5) normally exempts organizations with fewer than 250 employees from keeping full records, but that exemption falls away once special category data is processed, so even a small team needs a written record.
The practical work starts with a scoping decision. For each system that holds health, biometric, genetic or other special category data, record whether the processing is large-scale, whether it is a core activity, and which Article 9(2) exception is relied on. Those answers determine whether the DPIA, the DPO designation and the record are needed. Confirm the exact thresholds for "large-scale" with your supervisory authority's guidance and with counsel, because the GDPR does not define a numeric cutoff in the text. The DPIA should describe the data flows, the systems storing the data, and the access paths, since those are the facts a reviewer will test against your security controls.
The record of processing for these activities should name the special category, the Article 9(2) exception, the systems and sub-processors involved, the retention period and the security measures in place. Keep it current when a new integration starts, because the record is only useful if it matches the running environment. If a DPO is appointed, the DPO should review the DPIA and the record, and the organization should confirm that the DPO has the independence and resources the role requires. Ask your legal team to confirm whether national rules add conditions to the processing of health, genetic or biometric data under Article 9(4), since those conditions can change what the DPIA and record must show.
Evidence that satisfies Article 9 and how to keep it current
Article 9 compliance is shown through a small set of linked records: what special category data you hold, the exception that justifies each use, who can reach it, and how it is protected. Each artifact below needs a named owner and a refresh trigger, because an inventory or access review that is a year old no longer describes the systems an assessor will test.
Special category data inventory
A current list of every system, dataset, field and log where health, biometric, genetic or other Article 9(1) data appears, including data that arrives incidentally in free text, support tickets and backups. Record the data element, the purpose, the storage location and the owning team. Refresh it whenever a new integration, schema change or analytics export is approved, and check it against actual schemas rather than design documents. Ask whether the inventory covers derived data such as risk scores that reveal health status.
Article 9(2) exception register
For each processing purpose involving special category data, record the specific Article 9(2) exception relied on, the Article 6 lawful basis, the justification and the date of last review. Where explicit consent is the exception, link the register entry to the consent records themselves. Where Member State conditions apply to genetic, biometric or health data under Article 9(4), note the national rule. Review entries when purposes change or a new country's law becomes relevant.
Consent records for explicit consent
Where explicit consent is the exception, the system must hold evidence of what the person was told, when they agreed, which version of the notice applied and whether they later withdrew. Check that withdrawal stops the processing in every downstream system, not only the front end. Sample consent records at each review and confirm that no special category processing continues after withdrawal or outside the consented purpose.
Access review results
Periodic certification of who can read special category datasets, including administrators, support staff and service accounts. Reviewers should decide within a set timeframe whether each access item is kept, changed or revoked, and the campaign output becomes the evidence. Open-source identity governance tools such as midPoint support this workflow through access certification campaigns. Confirm that reviewers are not the same people who requested the access.
Encryption and key management configuration
Record how special category data is encrypted at rest and in transit, where keys live and who can rotate them. Server-side encryption in Nextcloud protects file contents with keys held on the server, but it does not hide file names or folder structure, so health-related naming conventions need their own control. Application-level encryption through OpenBao's transit engine supports versioned keys and rotation. Capture configuration exports and rotation logs at each review.
DPIA, processing records and automated decision safeguards
Large-scale special category processing needs a DPIA and, where it is a core activity, a DPO. Keep the DPIA, the record of processing entries for each purpose, and any automated decision logic that uses special category inputs with its safeguards, such as human review and the explicit consent or substantial public interest basis required by Article 22(4). Re-open the DPIA when the system, data volume or model changes materially, and confirm each record still matches the inventory.
What meeting Article 9 costs in money and effort
This table breaks down the cost and effort components of meeting Article 9 for special category data, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Read it to scope a quote, and note that no price figures are given because none are supplied for this topic.
| Cost component | Who is paid or who bears it | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Discovery and data mapping | Internal privacy and IT staff, plus any outside implementation partner for system inventory | One-time, then recurring when new systems are added | Number of systems holding special category data, and how much free-text content they store |
| Engineering for segregation and encryption | Platform engineers or an implementation partner for separated stores, keys and access paths | Mostly one-time, with recurring key rotation and upkeep | Number of separated datasets, key hierarchy design, and whether encryption is added to existing data |
| Access certification effort | Designated reviewers in each business unit, plus platform staff who run campaigns | Recurring, at each review cycle | Number of users and role assignments touching special category data, and how often reviews run |
| DPIA and legal review | Internal DPO or privacy lead, legal counsel, and any outside DPO or consultant | One-time per processing activity, then recurring on change | Number of processing purposes, reliance on Article 9(2) exceptions, and Member State conditions under Article 9(4) |
| Exception and basis documentation | Privacy and legal staff who record the Article 9(2) exception for each purpose | One-time per purpose, then recurring on review | Number of exceptions relied on and how often purposes change |
| External review and auditor sampling | Independent auditor or assessor, paid by the organization | Recurring, at each assessment cycle | Sample sizes the auditor selects, volume of evidence, and number of in-scope systems |
| Software licenses | Commercial vendors for encryption, key management or access governance tools | Recurring license fees | Where self-hosted open-source platforms such as OpenBao or midPoint replace commercial licenses, this line can fall, though support costs remain |
| Ongoing support and retainers | Implementation partner or internal platform team | Recurring, when agreed in writing | Change volume, upgrade frequency and the depth of evidence the organization wants to keep |
Open-source tools that produce Article 9 evidence
Where special category data sits in documents, uploads or shared folders, encryption at rest is often the first control an assessor asks about. Nextcloud offers server-side encryption that protects file contents on local and external storage, with keys held on the server. That gives you a configurable mechanism and a configuration you can show, but it is not a complete answer for Article 9 data.
- Content protection: Server-side encryption covers file contents at rest on supported storage, so the evidence is the enabled configuration and key handling, not a general statement about encryption.
- File names are not covered: File names and folder structure remain visible, so a folder called with a health condition or a union name can still disclose special category information.
- Key custody: Because keys are kept on the server, the controller must decide whether that model meets its risk assessment for health or biometric data.
- Access still matters: Encryption at rest does not stop an authorized user from reading a file, so pair it with access controls and logging.
- Licence fit: Nextcloud is licensed under AGPL-3.0-only. Confirm with your legal team that this licence works for your deployment and any modifications you make.
Before relying on this control, check the encryption configuration documentation for your Nextcloud version and test how file names and metadata appear in your storage backend.
Applications that store or process special category data, such as patient records, biometric templates or case notes, need encryption that the application can call without holding raw keys. OpenBao's transit secrets engine provides that pattern: the application sends data to be encrypted or decrypted, and the engine performs the operation without storing the data. This separates key management from the application database and produces evidence of key use.
- Encryption as a service: The transit engine encrypts and decrypts application data without storing it, so ciphertext can live in your database while keys stay in the engine.
- Signing and verification: The engine can also sign and verify data, which helps show that records were not altered after capture.
- Versioned keys and rotation: Versioned encryption keys support key rotation, so you can show when keys changed and how older ciphertext is handled.
- Operational ownership: Your team runs the service, backups and unseal process, so document who holds the recovery material and who may request operations.
- Licence fit: OpenBao is licensed under MPL-2.0. Confirm the obligations that apply if you modify its source code.
Review the OpenBao transit documentation for the version you deploy, and test that a rotated key still decrypts the records you must keep.
Encryption does not answer whether the right people can see special category data. Access certification campaigns do. midPoint runs campaigns in which designated reviewers decide, within a set timeframe, whether to keep, change or revoke access items such as role assignments. Used on systems that hold sensitive records, this produces dated decisions that show access was reviewed.
- Scoped campaigns: Define campaigns around systems and roles that reach special category data, such as clinical records, HR case files or biometric enrolment stores.
- Named reviewers: Assign reviewers who understand the data and the business need, and record their decisions, including revocations.
- Accumulation and segregation: Campaigns counter access build-up over time and help check segregation of duties between roles.
- Evidence trail: Keep campaign results, deadlines and remediation tickets together so an assessor can trace a decision to an action.
- Licence fit: midPoint is licensed under EUPL-1.2+. Confirm how the EUPL applies to your distribution and integration work.
Check the midPoint access certification documentation for the features in your release, and confirm that your reviewers can see the data context they need to decide.
Article 9 work produces many linked artifacts: DPIAs, records of processing, legal bases for each special category, and control evidence. CISO Assistant helps track these against frameworks. It ships with more than 200 frameworks, including GDPR, and runs audits and compliance assessments against them with automatic mapping between frameworks. It organizes evidence, but it does not decide whether your processing is lawful.
- Framework library: GDPR is among the frameworks included, so you can track assessment questions and findings against the regulation in one place.
- Assessment records: Use it to record which controls you assessed, who reviewed them, and what evidence supports each answer.
- Mapping caution: Automatic mapping between frameworks is a feature of the tool, but treat any mapping as something to verify against the texts before you rely on it for an assessor.
- Human judgment stays with you: The legal basis, the Article 9(2) exception and the DPIA conclusion are decisions for your data protection team.
- Licence fit: CISO Assistant is licensed under AGPL-3.0-only. Confirm the licence position with counsel before you embed or redistribute it.
Confirm the GDPR framework content and any mapping in the version you install against the official regulation text before using it in an assessment.
Where organizations fall short on special category data
Most gaps around Article 9 are not about missing policy. They come from sensitive values that spread quietly into systems nobody designed for them, such as logs, backups and support exports, and from decisions that were never recorded. Each card pairs one common gap with the action that closes it.
Sensitive fields in logs and backups
Health, biometric or religious data often reaches application logs, error traces, analytics events and backup sets, where access controls and retention rules are weaker than in the primary database. Once a special category value sits in these copies, the Article 9 prohibition applies to them too, even though no one designed them to hold that data. Check whether logging libraries and backup jobs capture request bodies and free-text fields, and exclude or mask those fields at the source.
Exceptions never written down
Teams often know why sensitive data is processed but never record which Article 9(2) exception they rely on, so the basis cannot be shown to a supervisory authority. Without a record, a later change to the feature can silently remove the exception. Record the specific exception, the processing purpose and the owner for each special category data flow in the record of processing.
Consent used where another exception applies
Explicit consent is the exception most often reached for, yet it can be withdrawn at any time and is weak in employment relationships where the power balance is unequal. Where employment law, health care or a substantial public interest already provides the exception, relying on consent creates a withdrawal path the system must then honor. Confirm which exception fits each purpose before building a consent screen, and document why consent was or was not chosen.
Access accumulation to sensitive records
Staff who change roles often keep access to health or biometric records from earlier duties, and service accounts accumulate broad read rights over time. Access that exceeds the documented exception is a processing outside the lawful basis, regardless of intent. Run periodic access reviews on every system holding special category data, with named reviewers who must keep, change or revoke each item.
Secrets protecting sensitive data
Encryption keys for special category stores are often held in configuration files or shared administrator accounts, which makes encryption at rest a weaker control than it appears. Anyone who can read the key can read the data. Move key material into a dedicated secrets service with versioned keys and scheduled rotation, and confirm who can request decryption.
Automated decisions using health or biometric inputs
Scoring, triage or access-control models that take health readings, facial templates or voice patterns as inputs fall under the automated decision rules and need an explicit exception plus safeguards. Teams often add these inputs to a model without reviewing the decision logic. Before any model consumes special category inputs, confirm the Article 22(4) basis, the human review route and the explanation a data subject can receive.
Questions buyers ask about Article 9 effort and outside help
How much effort does Article 9 compliance take for a system that processes health data?
Effort depends mostly on how many systems hold special category data, how many processing purposes rely on each Article 9(2) exception, and how much of that data already sits in documented, access-controlled stores. The GDPR sets no hours or headcount, so the figure comes from your own inventory. Teams usually spend the most time on three tasks: mapping where health, biometric or genetic data enters and leaves systems, recording the exception that applies to each purpose, and confirming that encryption, access reviews and logging cover those stores. Ask any partner to show how their estimate follows from that inventory rather than from a generic daily rate.
How long does discovery usually run before implementation starts?
No supplied figure gives a standard duration, so treat any timeline as a function of scope. Discovery is shorter when the data inventory already exists and longer when processing is spread across SaaS tools, legacy databases, logs and backups. Discovery normally covers the records of processing entries that involve special categories, the Article 9(2) basis per purpose, the DPIA trigger analysis under Article 35(3)(b), and the DPO question under Article 37(1)(c). Ask for the discovery deliverables and their scope in writing before agreeing a start date.
What does the work need from our side?
Most of the work depends on decisions and access only your organization can provide. Expect to supply:
- A named business owner for each processing purpose and its Article 9(2) exception
- Read access to data stores, identity systems, logs and backup configurations
- Access to your existing DPIA, records of processing and retention rules
- Time from legal or the DPO to confirm whether a basis such as explicit consent or substantial public interest applies
Without these inputs, a partner can prepare technical controls, but it cannot decide which exception is lawful. Make sure the quote lists these dependencies explicitly.
Can our in-house team handle Article 9 work without an outside partner?
Yes, a capable internal team can do much of this work, provided it has time, the right skills and clear decision rights. Internal teams usually handle the legal basis analysis and the business ownership, since those rest with the controller. Outside help is most useful for the technical evidence: configuring encryption at rest, separating key custody, setting up access certification campaigns, and producing logs that show who viewed special category records. Check whether your team can produce that evidence on demand, because a regulator will ask for it.
When is it worth bringing in an outside partner for special category data?
Bring in a partner when the inventory is large, when special category data flows through systems you did not build, or when you need an implementation the team does not have time to deliver. A partner also helps when DPIA or prior consultation work must be documented carefully. DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure and prepares systems and evidence for assessment. It does not decide the lawful basis for your processing and does not issue audit reports or certificates. Independent auditors and supervisory authorities perform those roles.
What drives the cost of an Article 9 engagement up or down?
Cost moves with scope, not with the article number. The main drivers are the count of systems holding special category data, the number of distinct purposes and legal bases, the state of existing documentation, and whether data already runs on self-hosted or managed infrastructure. Costs are one-time for the design, deployment and evidence set, and recurring for reviews, access certifications and retention checks. Ask for a fixed-scope quote that separates these two categories, and check whether it covers DPIA support, the record of processing updates and post-go-live evidence.
Which open-source tools can produce evidence for special category controls?
Several self-hosted tools can generate parts of the evidence, and each covers a different control. Nextcloud server-side encryption protects file contents at rest, but it does not encrypt file names or folder structure, so confirm that gap with your own data design. OpenBao's transit secrets engine can encrypt application data with versioned keys and rotation. midPoint access certification campaigns let designated reviewers keep, change or revoke access within a set timeframe. CISO Assistant can organize GDPR assessments alongside other frameworks. Confirm each product's current capabilities against its documentation before you rely on it.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares the systems and evidence behind Article 9 Processing of special categories of personal data. We do not issue assessments or opinions on your compliance; that role belongs to your data protection authority, your own assessors or an independent auditor.
How we scope
- Written scope lists which special category data sets, systems and processing purposes fall under Article 9(1) and which Article 9(2) exception you rely on.
- Scope identifies the systems holding health, biometric, genetic or other sensitive data, including backups, logs and search indexes.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.
How we build
- We configure encryption for sensitive files and applications, and confirm which metadata such as file names and folder structure remains unencrypted.
- We set up key management with rotation and access controls, so application-level encryption keys are separated from the data they protect.
- We configure access certification reviews for staff who can reach special category data, with reviewers and review timeframes documented.
How we hand over
- Deliverables include configuration records, data flow descriptions and a record of processing entries covering each special category data set.
- We document the inputs your DPIA needs for high-risk special category processing, so your team or assessor can complete and review it.
- Handover covers runbooks for access reviews, key rotation and deletion jobs, so your staff can run the controls after delivery.
How we support
- Retainers cover upgrades, hardening, backup and restore testing and periodic review of the controls protecting special category data.
- Security testing of applications and APIs that handle sensitive data can be scoped separately and run against the agreed environment.
- Ask any provider to confirm in writing who decides the Article 9(2) exception, who signs the DPIA and who performs any DPO role.
