Article 32 Security of processing: requirements and evidence

What Article 32 security of processing asks for in practice

Article 32 requires controllers and processors to implement technical and organisational measures that give a level of security appropriate to the risk. It does not supply a fixed checklist of controls that every organization must install. The obligation is to choose measures that fit the risks to individuals, then to be able to show why those measures were the right ones. The regulation places this duty on both controllers and processors, so a SaaS provider running a platform for customers carries its own share of the obligation even when the customer decides what data is collected.

The difficulty is that the appropriate level must be justified, not just claimed. Article 32(1) asks you to weigh the state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risks to individuals. Article 32(2) then directs attention to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data. Article 32 names four kinds of measure, including pseudonymisation and encryption, but it leaves the selection to the organization. A supervisory authority will therefore ask what risks you identified, what you decided and why, and whether the measures you chose work in practice.

The GDPR requires no audit, attestation or certificate, so the evidence is the justification itself: a documented risk assessment, the measures mapped to the risks, and records showing those measures run. Certification under Article 42 is voluntary and, under Article 32(3), can be used as one element of demonstrating compliance, but it does not reduce your responsibility. Before you start, confirm which personal data flows fall under your role, which processors touch them, and who owns the decision on residual risk, because those answers determine what the justification must cover.

Which processing, systems and parties Article 32 reaches

Article 32 applies to the processing a controller or processor actually performs, so scope is set before any control is chosen. The decisions below determine which datasets, stores, vendors and hosting arrangements must be assessed, and each wider boundary adds risks to the assessment.

Controller or processor, per dataset

Article 32 binds both roles, but the duties attached to each differ. For every dataset, record whether the organization decides why and how the data is processed (controller) or handles it on another party's documented instructions (processor). A single company often holds both roles across products, so the answer can change from one dataset to the next. Confirm the role with counsel before writing the security baseline, because a wrong role leads to measures aimed at the wrong obligations.

Production, backups, logs and copies

Personal data rarely sits only in the production database. List every store that holds it: primary databases, object storage, backups and snapshots, application and access logs, analytics warehouses, search indexes, exports and test copies. Each store carries its own risks of loss, alteration or unauthorised access, and Article 32(2) asks for those risks to be considered. A test copy that was never masked is a common gap that auditors and regulators find.

Third parties and sub-processors

Identify every outside party that can reach personal data, including hosting providers, support tools, managed service staff, payment and email services, and the sub-processors those vendors use. Each one extends the processing boundary and the risk picture. Ask each vendor for its own security commitments and for the list of sub-processors, and note which of them can access data in clear text rather than only storing it.

Self-hosted systems in your own environment

When platforms run in the organization's own cloud account, data center or air-gapped network, those systems are part of its processing and fall inside its Article 32 assessment, including administrative access, patching, backup jobs and monitoring. Hosting in your own environment does not remove risk, it shifts ownership of it to your team. Document who operates each component and who holds administrative credentials, because those answers decide which measures you must evidence.

Environments and privileged access paths

Scope also covers the environments that touch production data, such as staging, disaster recovery sites, build pipelines, remote support sessions and engineer laptops. Map each path by which an administrator or support engineer can reach personal data, including break-glass accounts and vendor access tunnels. Paths that bypass the main controls are where the security assessment most often finds gaps, so they should be listed explicitly.

Cross-border flows and wider scope

Where data crosses borders, whether to a foreign hosting provider or a remote support team outside the EEA, the transfer path becomes part of the processing being assessed. Every additional store, vendor, environment or country increases the number of risks that must be weighed against the state of the art and implementation costs. Record the scope boundary in writing, review it when systems change, and confirm the interpretation with your data protection lead.

How the appropriate level of security is set

Article 32(1) does not fix a list of security measures for every controller. It asks for a level of security appropriate to the risk, and the controller or processor sets that level by weighing several inputs together: the state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risks to individuals. The weighing is the obligation. A file that shows only which tools were bought does not show that this weighing happened, so the reader should be able to point to a written record of how each input was considered for each processing activity, and when it was last revisited.

Article 32(2) narrows the risk side of that weighing. It directs the controller or processor to account in particular for accidental or unlawful destruction, loss or alteration of personal data, and for unauthorised disclosure of or access to it. In practice, a risk assessment for a system holding personal data should name these four outcomes for that system's data, then identify the realistic paths to each one, such as a misconfigured storage bucket, a shared administrator account, an unpatched internet-facing service or a faulty software update. Each path should map to a control and to an owner who can show it working. Cost is a real input, but it is one of several and it cannot justify leaving a known, material risk unaddressed. If a cheaper control does not reduce the identified risk, the reader should expect a regulator to ask why the more expensive option was rejected, and should document that decision before an incident forces the question.

Article 32(3) allows an approved code of conduct or an approved certification mechanism to be used as an element in demonstrating compliance with Article 32(1). Article 42 certification is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the responsibility of the controller or processor. Organizations should therefore treat any certificate as one input to their own evidence file, not a substitute for it. Before relying on one, confirm with the certifying body which processing activities and which version of the scheme it covers, and whether the certificate is current. An implementation partner can prepare the risk assessment and evidence, but only an accredited body can issue a certification.

How an assessor tests whether security is appropriate

This table shows how a supervisory authority or customer's auditor tests whether Article 32 security is appropriate, what each test asks for, and where organizations usually fall short. The supervisory authority or a customer's auditor performs these tests, while DeployOpen only prepares the systems and evidence the tester reviews. Read each row as a question the organization must be able to answer with dated, specific records.

Test question	Test approach	Evidence requested	Common findings
Is there a documented risk assessment per processing activity?	Sample processing activities and check whether each has its own risk analysis covering destruction, loss, alteration and unauthorized disclosure or access.	Dated risk assessments per activity, risk owner sign-off, and the data categories and volumes they cover.	One generic assessment for all systems, or assessments that were never updated after a new system or data source was added.
Do the chosen measures follow from the identified risks?	Trace each high-rated risk to a named control and check that the control addresses that risk.	Risk register linked to a control list, with residual risk stated and accepted by a named role.	Controls listed as present but not tied to any risk, or high risks with no measure and no documented acceptance.
Do the records of processing describe the measures?	Compare the general description of security measures in the processing records with the systems actually in place.	Records of processing with a current description of Article 32(1) measures for each activity.	Descriptions copied from a template that do not match the live environment, such as encryption or MFA claims that are not deployed.
Is state of the art and cost reasoning documented?	Check whether the organization considered current practice and implementation cost, and whether it recorded why a weaker option was chosen.	Decision records or memos comparing options, with the reasoning and the date of the review.	No record of the reasoning, or a cost argument for skipping a control that the risk level plainly required.
How are known incidents and near misses handled?	Review past incidents and check whether root causes led to changed measures, and whether the same weakness recurred.	Incident tickets linked to corrective actions, and evidence the changes were tested.	Incidents closed without a control change, or the same access or configuration weakness appearing in later incidents.
Is processor oversight adequate?	Check how the controller selected processors, what security terms the contract sets, and how their performance is verified.	Processor due diligence files, security terms in contracts, audit reports or questionnaires received, and review dates.	Processors chosen on price alone, contracts without security terms, or no check that the processor's controls still operate.

Steps to build a risk-based security assessment that holds up

This sequence turns Article 32 from a general duty into a documented assessment: each processing activity has known systems, named risks, reasoned measures, current records, accountable owners and a first set of evidence an assessor can test.

Build a processing and data inventory per system
Start by listing each system, service and business process that handles personal data, and for each one record the categories of data, the data subjects, where the data is stored and moved, which internal teams and external processors touch it, and the purpose it serves. Engineering and the business owner should confirm the list together, because systems that are missing here will be missing from every later step. The output is a signed-off inventory with one entry per processing activity, and you know it is done when someone outside the project can trace a data flow from collection to deletion using only the inventory.
Run a risk assessment for each processing activity
For each activity in the inventory, assess the risks to individuals using the four risk types named in Article 32(2): accidental or unlawful destruction, loss, alteration, and unauthorised disclosure of or access to personal data. Rate likelihood and severity from the perspective of the people whose data is affected, not only the organization's operational exposure, and record the assumptions behind each rating. The output is a risk register per activity, and it is complete when every activity has a rating for each of the four risk types, even where the rating is low.
Map each risk to measures and record the reasoning
For each rated risk, identify the technical and organizational measures that reduce it, and write down why the chosen level is appropriate given the state of the art, the implementation cost, and the nature, scope, context and purposes of the processing. Where a cheaper or weaker option was rejected, record that decision and its reason, since an assessor will ask why a control was not adopted. The output is a risk-to-measure map with a short rationale per entry, and it is done when each residual risk has an accepted owner and an explicit justification.
Update the records of processing with measure descriptions
Carry the measures from the assessment into the records of processing that Article 30 requires, which must include a general description of the Article 32(1) measures where possible. The records should describe the measures in enough detail that a supervisory authority reading them can tell what protects each activity, without restating the full security policy. The output is updated records for every activity in the inventory, and it is complete when the records and the risk register point to the same measures.
Assign owners and set a review cadence tied to change
Name one accountable owner for each processing activity and each residual risk, and define the triggers that force a re-assessment, such as a new system, a new processor, a material change in data volume, or a confirmed incident. Calendar reviews as a backstop, and confirm with the owners how they will be told when a trigger occurs. The output is an owner register and a review procedure, and you know it works when a recent change, such as a new software installation, produced a documented update to the assessment.
Collect the first evidence set
Gather the artifacts that show the assessment was performed and that the measures exist: the inventory, the risk register, the rationale records, the updated records of processing, the owner register, and samples of configuration or test output that support the stated measures. Store them in a location with version history so that the state at any date can be reconstructed. The output is a dated evidence set, and it is done when an internal reviewer can pick any activity and follow the chain from data inventory to risk, measure, owner and proof. Ask any external auditor or certification body which formats they expect before you assemble it.

Evidence that shows an appropriate level of security

Article 32 does not prescribe a document set, but a supervisory authority will expect to see how the controller or processor reached its security decisions and whether those decisions stayed current. The cards below cover the records that connect risk, measures and change over time, plus the tooling that can generate operational evidence.

Signed risk assessment per processing activity

A dated, approved assessment for each processing activity that records the data categories, the people affected, the threats considered (accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access) and the likelihood and impact used to rate them. Check that the assessment names an accountable owner and that the rating method is written down, so a reviewer can see why one activity received stronger measures than another.

Risk treatment register

A register that links each identified risk to the measures chosen to treat it, the residual risk accepted, and the person who accepted it. Auditors and regulators use it to test whether measures were selected because of a specific risk. Gaps usually appear where a risk has no linked measure or where a measure is listed but has no owner or test date.

Records of processing entries describing measures

Article 30 requires the record of processing to include, where possible, a general description of the Article 32(1) measures. Each entry should describe the actual controls for that activity, such as encryption, access control and backup, rather than repeating a generic policy statement. Confirm that entries match the current architecture, because a record that describes a retired system is weak evidence.

Security architecture and configuration baselines

Diagrams of the systems that hold personal data, together with hardened configuration baselines for servers, databases, identity providers and network zones. These show how the measures are built, not only that they were planned. Keep baseline versions under change control and retain the deviations approved for each system, so a configuration check can be compared against a known standard.

Processor contracts and sub-processor reviews

Where a processor or sub-processor handles personal data on your behalf, the contract should set the security measures expected and the review cycle for them. Keep evidence of the review itself, such as the assessment of the provider's controls, the date it was done and any follow-up actions. Confirm that the sub-processor list used in your records matches the one the provider actually operates.

Review log showing re-assessment after change

A log that records when the risk assessment, register and records of processing were reviewed, and what triggered each review, such as a new system, a breach, a vulnerability finding or a change of processor. Regulators look for evidence that security was re-evaluated when conditions changed, not only at the first assessment. Entries should show who reviewed, what changed and what was decided.

Open-source tooling that produces evidence

Several self-hosted tools can generate parts of this evidence. CISO Assistant (AGPL-3.0-only) supports framework-based assessments and includes GDPR among its frameworks. DefectDojo (BSD-3-Clause) imports and deduplicates findings from many tool formats. Greenbone Community Edition (AGPL-3.0-or-later) stores scan results in PostgreSQL, and OpenSearch Security Analytics (Apache-2.0) records Sigma-rule detections with alerting. Confirm each tool's fit and licence obligations against your own needs before adoption.

What meeting Article 32 costs in money and effort

This table breaks the cost of meeting Article 32 into components, showing who is paid for each, whether it is one-time or recurring, what drives it up and how to keep it down. No price or duration is given because the supplied facts contain none, so use the table to structure a written quote and to compare what each vendor or consultant includes.

Cost component	One-time or recurring	What drives it	How to keep it down
Risk assessment labor	One-time, then recurring on review	Number of processing activities, data categories, and systems in scope under Article 32(1) and 32(2)	Start from a defined scope by processing activity and reuse the assessment across similar systems
Tooling and licenses	Recurring	Commercial tool subscriptions; open-source tools such as DefectDojo or Greenbone remove license spend but not hosting or staffing	Confirm licensing terms for each tool and budget for hosting, storage, and administrator time separately
Engineering time to implement measures	One-time, with later changes	Gaps against the measures the risk assessment selects, such as access control, logging and encryption	Prioritize measures by identified risk and sequence work to match existing change windows
Documentation of measures	One-time, then recurring	Need to describe Article 32(1) measures in the records of processing and in technical standards	Write documentation alongside implementation rather than afterward, and keep it in one controlled repository
Evidence upkeep after each change	Recurring	Frequency of system changes, new software installs, and personnel changes affecting access	Automate evidence collection where possible and assign an owner for each control's evidence
External testing or review	Recurring, often scheduled	Size and exposure of systems, and whether tests are independent of the implementation work	Define test scope in writing and reuse results when systems have not changed materially
Assessor or certification fees	Recurring if certification is pursued	Scope of the certification, number of sites and systems, and the certification body's own terms	Confirm that certification is voluntary under Article 42 and ask the body for a fixed scope in writing
Staff time for ongoing monitoring	Recurring	Log volume, alert handling, and the number of people responsible for reviewing findings	Tune detection rules to reduce noise and define clear escalation paths

What recent fines show regulators treat as inadequate

Two decisions issued in September 2026 show how supervisory authorities test Article 32 in practice: they look at the specific controls that failed, not at whether a policy existed. The cards below set out what each authority found, what it means for software and service providers, and where the fines stop being useful as a benchmark.

Swedish IMY fine against Miljödata

The Swedish supervisory authority, IMY, fined the IT service provider Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) in a decision of 22 September 2026. The fine followed a 2025 cyberattack that affected 2.2 million people. IMY cited inadequate checks when new software was installed and the absence of automated real-time monitoring for intrusions. Check whether your own change process tests new software before it reaches production and whether intrusion alerts fire without a person watching a console.

CNIL fine against Hôpital Privé de la Loire

France's CNIL fined Hôpital Privé de la Loire EUR 500,000 under Articles 32 and 34 in a decision of 3 September 2026. The regulator found that external access to the patient record system lacked a VPN and multi-factor authentication, and that access control ignored the need of care teams to know. Remote access paths and role-based access to health records are the first controls to test, because the failure was in who could reach the data and what they could see once inside.

Lessons for software and service providers

The Miljödata decision shows that a processor's own change and monitoring processes are within Article 32 scope, not only the customer's. If you install or update software for customers, record how each release is checked before deployment and how intrusions are detected across hosted systems. Confirm that your customer contracts describe these controls, since a regulator will ask what the processor actually did, not what the customer was promised.

What the fines do not decide

The fines do not set a general price for compliance, and they do not show that a particular tool or certificate is required. Each decision turned on specific facts, including the data involved, the controls that were missing and the harm that followed. Use them to decide which failure modes to test first, and get a written risk assessment from your own environment before budgeting. Ask any consultant to show how they reached a recommendation from your facts.

Who does what: your team, an implementation partner and the auditor

Article 32 places the security obligation on the controller and the processor, so the decisions stay with your organization even when outside specialists do the building. Your team decides what risk the processing carries for individuals, which measures are appropriate given the state of the art and implementation costs, and how much residual risk leadership is willing to accept. Those decisions belong in written form, with a named owner and a review date.

Risk decisions: Set the risk assessment method, rate the risks to individuals, and approve the measures chosen to address them.
Residual risk: Record which risks remain after controls are applied and who accepted them.
Processing records: Sign and maintain the records of processing, including the general description of security measures that Article 30 asks for where possible.
Production ownership: Run the controls day to day, including access reviews, patching, monitoring and restore tests.
Evidence custody: Keep logs, approvals and test results in a place where they can be produced on request.

Confirm internally who signs the risk acceptance and whether that person has authority over the systems the decision covers.

Questions buyers ask about Article 32 cost, effort and help

How much effort does an Article 32 security assessment take?

The effort depends mainly on how many processing activities and systems fall in scope, how much personal data each one holds, and how mature the existing security documentation is. Article 32(1) asks for measures appropriate to the risk, so the work starts with a risk assessment of each processing activity, followed by a review of the measures already in place against that risk. Organizations with few systems and current documentation finish far sooner than those with many legacy platforms, undocumented data flows or several processors. No duration is supplied for this work, so ask any partner to state the number of systems, data stores and interfaces their written scope covers before agreeing an effort figure.

Can a small team run the Article 32 assessment in-house?

A small team can usually run the assessment in-house if it has someone who understands both the processing activities and the technical controls, and if the scope is limited to a few systems. The harder parts are usually the risk analysis, which needs business and legal input, and the technical testing, which needs people who can read configurations and logs without bias toward their own work. Many teams keep ownership of the controls and bring in an outside party for an independent review of the risk assessment or for testing. Be clear with yourself about who signs off the decisions, because the controller remains responsible for the level of security chosen.

What does the client need to provide for an Article 32 review?

The review needs named system owners, current architecture documents and access to the evidence that shows how systems actually behave. In practice this means:

A list of processing activities, the systems that support them and the owner of each system
Network and data flow diagrams, including processors, sub-processors and hosting locations
Read access to access control lists, identity provider settings, encryption configurations and backup policies
Access to logs, monitoring alerts and recent vulnerability or change records
Existing records of processing, risk registers and any previous incident reports

Without these inputs, the assessment ends up describing intentions rather than controls, and assessors will not accept it as evidence.

How long does it take to meet Article 32 requirements?

The time needed depends on the drivers below, and no duration is supplied for them here. The first driver is the number of processing activities and systems in scope. The second is whether the organization already has a current risk assessment and tested controls, or must build them. The third is how many gaps the review finds and how much change those gaps require, such as new authentication, logging or backup tooling. The fourth is the availability of system owners and approvers for decisions. Ask any partner to split its proposed timeline into the assessment, remediation and evidence collection phases, and to state which of those depends on your internal reviews.

Does ISO/IEC 27001 certification satisfy Article 32 of the GDPR?

No, certification does not automatically satisfy Article 32, but it can help. Article 32(3) says that adherence to an approved code of conduct or an approved certification mechanism may be used as an element to demonstrate compliance with Article 32(1). Note that the wording says element, not proof. An ISO/IEC 27001 certificate covers an information security management system, and the scope of that certificate must be checked against the processing activities you need to demonstrate. Certification under Article 42 is a separate mechanism issued by accredited bodies or supervisory authorities, and any certification does not reduce the controller's or processor's responsibility for compliance. Check with your supervisory authority or counsel how a given certificate will be weighed.

Can DeployOpen issue a GDPR or Article 32 compliance certificate?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body can issue those documents. The GDPR itself requires no audit or certificate, and Article 42 certification is issued by accredited certification bodies or supervisory authorities. DeployOpen's role is to plan, implement and document the technical controls on your self-hosted open-source platforms, run security testing, and prepare the evidence your chosen assessor will examine. Your organization still owns the controls and the compliance decisions.

What should a fixed-scope quote for Article 32 work include?

A written, fixed-scope quote should state exactly what is in and out of scope before work begins. Ask the partner to specify:

The processing activities, systems, environments and locations covered
The deliverables, such as a risk assessment, control gap list, configuration changes, test reports and evidence packs
The roles of each party, including which controls you own and which the partner prepares
The assumptions about your inputs, access and availability of system owners
What is one-time work and what is a recurring retainer for upgrades, monitoring or continuous testing
The milestones and acceptance criteria for each deliverable
Any third-party costs for licenses, hosting or external assessors

A quote following from this written scope is the only reliable basis for comparing offers.

How DeployOpen scopes and prepares Article 32 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the security measures Article 32 asks for can be shown in your systems. DeployOpen prepares the controls and evidence; your organization owns the controls, and an independent auditor or certification body issues any report or certificate.

How we scope

The written scope names the processing activities, systems and personal data categories covered by the security review.
Scope records which Article 32(1) measures each system relies on and who in your organization owns each one.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Systems are configured with access control, MFA, encryption and logging settings documented against the agreed scope.
Security testing covers applications, APIs and infrastructure, so weaknesses are found before evidence is collected.
Backup, restore and monitoring components are set up so their results can be recorded and reviewed over time.

How we hand over

You receive configuration records, test results and a description of the measures for your records of processing.
Runbooks explain how each control operates, how it is reviewed and how exceptions are recorded and approved.
Evidence is organized so your DPO, security team and any assessor can trace each measure to a system and owner.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover periodic reviews of risk assessments, configuration changes and newly added processing activities.
Ask any proposal to confirm who maintains each control and how changes to processing are reflected in the evidence.