Can NSAuditor perform the Article 32(2) risk assessment?

No. Art. 32(2) (account for the risks presented by processing) is an operator-side risk-assessment process — the GDPR analog of the HIPAA §164.308(a)(1)(ii)(A) Risk Analysis. The engine produces configuration state, vulnerability findings, and IAM-exposure substrate that INFORM the assessment, but it cannot perform it. Pair with your DPIA process (Art. 35) where applicable and a privacy-GRC platform (OneTrust / TrustArc / DataGrail).

How does cloud-provider ISO 27001 / SOC 2 / C5 adherence count under Article 32?

Article 32(3) allows adherence to an approved code of conduct (Art. 40) or certification mechanism (Art. 42) to be used as AN ELEMENT to demonstrate compliance — not a substitute. The cloud provider's ISO/IEC 27001 + SOC 2 + C5 (BSI) + EU Cloud Code of Conduct adherence is such an element for provider-controlled substrate only. It does NOT make the operator's public bucket compliant. Attestations are annual-currency: re-verify scope and validity each release cycle and at every privacy-program review.

GDPR Article 32 substrate the supervisory authority actually reads.

Q: Is this GDPR compliance? (No — Article 32 substrate only.)

No. This is NOT GDPR compliance and there is no such thing as a GDPR certificate under the Regulation. NSAuditor produces infrastructure-substrate evidence for the technical facets of GDPR Article 32 (security of processing) ONLY — one article of a 99-article legal regime. Every other article (lawful basis Art. 6, consent Art. 7, data-subject rights Arts. 12-23, records Art. 30, breach notification Arts. 33-34, DPIA Art. 35, DPO Arts. 37-39, transfers Arts. 44-49) is operator-side legal/process discipline and out of scope by design. This report is input to your Article 32 measures, not a whole-of-Regulation attestation.

Q: Is an unencrypted bucket automatically an Article 32 violation?

No. Article 32 applies to the security of processing of personal data. The scanner reads infrastructure state (encryption, access, availability) but cannot determine which resources actually hold personal data. An unencrypted bucket is an Art. 32 finding ONLY if it holds personal data; a public bucket of marketing assets is not. Pair every finding with your Article 30 Records of Processing Activities (RoPA) to confirm the resource is in-scope before treating an engine finding as an Art. 32 violation.

Q: What fine tier do Article 32 infringements fall under?

The LOWER Art. 83(4) tier — up to €10 million OR 2% of total worldwide annual turnover, whichever is higher. The famous €20M / 4% headline figure is the Art. 83(5) HIGHER tier and applies to basic principles, data-subject rights, and international transfers — NOT to Art. 32 security-of-processing infringements. Overstating fine exposure by quoting the headline number against an Art. 32 finding is itself an overclaim.

Q: Is the engine an absolute pass/fail verdict for Article 32?

No. Art. 32(1) measures are explicitly proportionate — 'appropriate to the risk'. The chapeau names four factors the operator must weigh: state of the art, costs of implementation, nature/scope/context/purposes of processing, and risk to the rights and freedoms of natural persons. The engine reads the substrate (encryption, redundancy, key management) and produces input FOR the operator's appropriateness determination; it does not — and cannot — make that determination.

NSAuditor AI EE produces an Article 32 (Security of Processing) infrastructure-substrate pre-audit report mapped per-sub-measure to Regulation (EU) 2016/679, Article 32. Signed artifacts, RFC 3161 trusted timestamps, SHA-256 chain-of-custody, four-factor proportionality discipline, Art. 83(4) lower-tier fine framing — and Zero Data Exfiltration because scan data never leaves your infrastructure. This is Art. 32 substrate only: it is not GDPR compliance, and no GDPR certificate exists under the Regulation.

✓ 4 sub-measures covered ⚠ 5 partial ⊘ 2 OOS-by-design ⚡ Art. 32 substrate ONLY Latest: EE 0.20.0 · 2026-06-12 · 7th framework

NEW · 0.20.0 · 2026-06-12 7th framework GDPR Article 32 (Security of Processing)

SHIPPED 2026-06-12 in EE 0.20.0 — GDPR Article 32 is the seventh supported framework

The engine reads data/compliance/gdpr.json per the framework-agnostic loadFrameworkMap loader; every GDPR (source, titlePattern) pair inherits from the grep-verified soc2.json pattern set. A single scan with --compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr produces all seven evidence packs from one finding stream. GDPR Art. 32 substrate joins the existing SOC 2, HIPAA §164.312, NIST CSF 2.0, PCI DSS v4.0.1, ISO/IEC 27001:2022, and CIS Controls v8 frameworks.

NSAuditor AI EE seven-framework hexagon — SOC 2, HIPAA, NIST CSF 2.0, PCI DSS, ISO 27001, CIS v8, and GDPR Article 32

TL;DR — the scoping doctrine
Four-factor proportionality discipline
Personal-data-scope attestation
Controller vs processor + Art. 28 DPA
Art. 83(4) lower fine-tier discipline
Coverage matrix — 11 sub-measures
Per-sub-measure substrate walk
Art. 32(3) / Art. 42 certification-inheritance
Rest-of-GDPR — OOS-by-design
How to run an Art. 32 scan
Zero Data Exfiltration — no new processor
Auditor / DPA FAQ

TL;DR — the scoping doctrine (read this first)

NSAuditor AI EE generates technical-substrate evidence for GDPR Article 32 (security of processing) — and ONLY for the infrastructure facets of that single article. It maps cloud infrastructure findings (AWS, Azure, GCP) and network scan results to specific Art. 32 sub-measures (Art.32(1)(a)-encryption-at-rest, Art.32(1)(b)-confidentiality, Art.32(1)(c)-restore-capability, …), produces signed evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, RFC 3161 trusted-timestamps, Ed25519 suppression signing — the same institutional-grade pipeline shipped for SOC 2 + HIPAA + NIST CSF 2.0 + PCI DSS + ISO 27001 + CIS v8), and emits machine-readable reports suitable for privacy-GRC ingestion.

The scoping doctrine — the most important paragraph on this page: The tool claims GDPR Article 32 infrastructure substrate and nothing more. Regulation (EU) 2016/679 is a 99-article legal regime. Article 32 (security of processing) is the only article whose evidence is technical infrastructure state; every other article is operator-side legal/process discipline, out of scope by design. This report is input to your Article 32 measures — it is not GDPR compliance, not a GDPR certificate (no such certificate exists under the Regulation), and not a substitute for any operator-side obligation.

It is not:

Whole-Regulation coverage. GDPR has 99 articles. This evidences the infrastructure facets of Art. 32 only. Lawful basis (Art. 6), consent (Art. 7), data-subject rights (Arts. 12–23), records of processing (Art. 30), breach notification (Arts. 33–34), DPIA (Art. 35), DPO (Arts. 37–39), and international transfers (Arts. 44–49) are all operator-side and OOS-by-design.
A personal-data classifier. The scanner reads encryption / access / availability state — it cannot determine which resources actually hold personal data. Every finding is an Art. 32 concern only if the resource processes personal data (see Personal-Data-Scope Attestation). Pair with your Art. 30 RoPA.
An absolute pass/fail verdict. Art. 32(1) measures are explicitly proportionate — "appropriate to the risk" (see the four-factor section). The engine produces substrate FOR the operator's appropriateness determination; it does not make that determination.
A risk-assessment (Art. 32(2)). The risk-assessment process is operator-side and OOS — the GDPR analog of HIPAA §164.308(a)(1)(ii)(A) Risk Analysis. The engine produces inputs to it; it cannot perform it.
A fine-exposure calculator. Art. 32 infringements sit in the lower Art. 83(4) tier (see below). Overstating fine exposure is itself an overclaim.

What it IS: the technical-substrate evidence layer for the Art. 32 sub-measures where cloud-infrastructure scanning can deterministically read the configuration state (encryption, access control, public exposure, availability protections, backup mechanisms, logging, IAM scoping). Every covered + partial sub-measure carries a stable controlObjective, proportionalityFactors, personalDataScope attestation, art83Tier, supervisoryAuthorityNote, and cloudProviderAttestation in data/compliance/gdpr.json.

The market split: privacy-GRC platforms (OneTrust, TrustArc, DataGrail) automate the records-of-processing / DSAR / consent / DPIA / breach-register workflow but lack deep cloud-infrastructure scanning; legacy scanners produce voluminous CVE reports but don't map findings to Art. 32 sub-measures. NSAuditor's wedge is the bridge — deep scanning + per-sub-measure-mapped Art. 32 substrate + the same Zero Data Exfiltration architecture used for the other six frameworks. Neither tool, standalone, is GDPR coverage — and this page never claims the engine is.

The four-factor proportionality discipline — nothing here is absolute pass/fail

Article 32(1) requires the controller and processor to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk." The chapeau of Art. 32(1) names four factors the appropriateness determination must weigh:

Factor	What it means	Engine's role
State of the art	The current technical baseline (e.g., TLS 1.2+, modern KMS-managed encryption)	Engine reads whether the substrate meets the current baseline (sub-TLS1.2, missing SSE)
Costs of implementation	The cost of a measure weighed against the risk it mitigates	Operator-side judgment — the engine cannot weigh cost
Nature, scope, context & purposes of processing	What data, how much, why, in what context	Operator-side — the engine does not know the processing purpose
Risk to the rights and freedoms of natural persons	Likelihood + severity of harm to data subjects	Operator-side risk determination, informed by engine substrate

The discipline: NOTHING the engine produces is an absolute pass/fail. A single-AZ database, a Microsoft-managed (vs customer-managed) key, an unencrypted store — each is substrate for the operator's "appropriate to the risk" determination, not a verdict. Appropriateness for special-category (Art. 9) data differs from appropriateness for low-sensitivity data. Each sub-measure in gdpr.json carries a proportionalityFactors array recording which of the four factors it most directly bears on (e.g., encryption → state-of-the-art + risk; availability → nature-scope-context-purposes + cost-of-implementation).

The engine emits substrate; the operator owns the proportionality call.

Personal-data-scope attestation — the scanner cannot know what holds personal data

Article 32 applies to the security of processing of personal data. The scanner reads infrastructure state (encryption enabled? public access? SSL enforced?) — it cannot determine which resources actually contain personal data. The consequences:

An unencrypted S3 bucket is an Art. 32 finding only if it holds personal data. A public bucket of marketing assets is not an Art. 32 violation.
An unencrypted transport channel is an Art. 32 concern only if it carries personal data. An HTTP endpoint serving only public static assets is not.
A confidentiality / public-exposure finding is an Art. 32 concern only if the over-exposed resource processes personal data.

Every covered and partial sub-measure in gdpr.json carries a personalDataScope field stating exactly this caveat. Pair every finding with your Article 30 Records of Processing Activities (RoPA) to confirm the resource is in-scope for personal-data processing before treating an engine finding as an Art. 32 violation. The Art. 30 RoPA is the GDPR analog of the HIPAA ePHI-scope determination and the PCI DSS Cardholder Data Environment (CDE) scope tag: the substrate is only a finding where the data is in scope.

Controller vs processor role applicability + the Art. 28 processor agreement (DPA)

Article 32 binds both controllers and processors ("the controller and the processor shall implement…"). Every sub-measure in gdpr.json carries roleApplicability: "both" — the substrate is relevant regardless of which role the operator occupies for a given processing activity.

Controllers determine the purposes and means of processing and own the overall appropriateness determination.
Processors process on the controller's documented instructions and must provide sufficient guarantees of appropriate Art. 32 measures (Art. 28(1)). The engine's substrate is the kind of "sufficient guarantee" evidence a processor supplies to a controller's vendor-assessment.

The Art. 28 processor agreement (Data Processing Agreement / DPA) is the contractual instrument documenting the instruction boundary. It is operator-side — the engine does not produce it. It is, however, the organisational complement to the Art.32(4)-instruction-bound-processing sub-measure: the engine's IAM least-privilege substrate technically enforces the instruction boundary that the Art. 28 DPA contractually documents. Neither half alone satisfies Art. 32(4).

Art. 83(4) fine-tier discipline — Art. 32 sits in the LOWER tier

Overstating fine exposure is itself an overclaim. Article 32 infringements fall under the Art. 83(4) administrative-fine tier:

Tier	Cap	What falls here
Art. 83(4) — LOWER	up to €10 million OR 2% of total worldwide annual turnover (whichever higher)	Article 32 (security of processing) + controller/processor obligations under Arts. 8, 11, 25–39, 42–43
Art. 83(5) — HIGHER (headline)	up to €20 million OR 4% of total worldwide annual turnover (whichever higher)	Basic principles (Arts. 5, 6, 7, 9), data-subject rights (Arts. 12–22), international transfers (Arts. 44–49) — NOT Art. 32

The famous "€20M / 4%" headline figure is the Art. 83(5) tier and does not apply to Art. 32 security-of-processing infringements. Every sub-measure in gdpr.json carries art83Tier: "83(4)-lower". When framing fine exposure from an Art. 32 finding, the correct ceiling is €10M / 2%, not the headline number. (Note: an underlying security failure can still draw an Art. 5(1)(f) "integrity and confidentiality" principle charge, which is Art. 83(5) tier — but that is an operator-side legal determination, not something the engine asserts from an Art. 32 substrate finding.)

Coverage matrix — 11 Art. 32 sub-measure units (4 covered / 5 partial / 2 OOS)

Source of truth is data/compliance/gdpr.json; this matrix mirrors it. Per-sub-measure (Art. 32(1)(a)–(d) + 32(2) + 32(4)) is the supervisory-authority-canonical citation unit — never the paragraph level. Every GDPR (source, titlePattern) pair inherits from the grep-verified soc2.json pattern set per the inheritance contract.

Sub-measure	Article	Measure	Substrate kind	Status / why
encryption-at-rest	32(1)(a)	Encryption of personal data at rest	KMS/CMK key state, server-side encryption, infrastructure double-encryption	✓ Covered — engine reads store encryption state directly
encryption-in-transit	32(1)(a)	Encryption of personal data in transit	Enforced TLS, minimum TLS version, SSL-enforced DB connections, cipher strength	✓ Covered — engine reads transport-encryption enforcement directly
confidentiality	32(1)(b)	Ongoing confidentiality of processing systems	IAM least-privilege, no public exposure, scoped key-vault/role grants	✓ Covered — engine reads access-control + public-exposure posture directly
availability	32(1)(b)	Ongoing availability of personal data	Soft-delete, versioning, backup, air-gapped vaults	✓ Covered — engine reads data-availability protections directly
integrity	32(1)(b)	Ongoing integrity of processing systems	Audit-trail / diagnostic logging substrate	⚠ Partial — logging substrate is necessary but not sufficient; operator change-detection + object-lock/WORM + tamper-investigation complete it
resilience	32(1)(b)	Ongoing resilience of processing systems	Multi-AZ / multi-region redundancy configuration	⚠ Partial — redundancy config is necessary substrate; operator DR drills + failover testing + documented continuity process complete it
restore-capability	32(1)(c)	Ability to restore availability + access after an incident	PITR, immutable / logically air-gapped backup vaults, lifecycle/retention	⚠ Partial (Class K) — engine evidences the restore MECHANISM; (c) requires restore-ABILITY, established only by a successful periodic restore TEST
testing-effectiveness	32(1)(d)	Process for regularly testing/evaluating effectiveness	Vulnerability mgmt, GuardDuty threat detection, CVE/EOL surfacing	⚠ Partial — the recurring scan is ONE input; operator pen-testing + DR drills + documented test-evaluate-remediate process complete it
instruction-bound-processing	32(4)	Persons under authority process only on instructions	IAM least-privilege, no privilege-escalation, no over-broad effective decrypt	⚠ Partial — IAM scoping is the technical half; the Art. 28 processor agreement + documented instructions + confidentiality undertakings are operator-side
pseudonymisation	32(1)(a)	Pseudonymisation of personal data	—	⚪ OOS-by-design — a data-model decision wholly outside the scanner's visibility; the encryption siblings are adjacent 32(1)(a) measures but credit nothing here. Operator attests per the data model
risk-assessment	32(2)	Account for the risks presented by processing	—	⚪ OOS-by-design — an operator-side risk-assessment process (GDPR analog of HIPAA §164.308(a)(1)(ii)(A) Risk Analysis). The engine produces substrate that INFORMS it; it cannot perform it

Totals: 4 covered + 5 partial + 2 OOS = 11.

Why the two OOS units are OOS and not partial

Art. 32(1)(a) pseudonymisation: Art. 32(1)(a) names BOTH pseudonymisation AND encryption. Encryption is substrate-rich (the two covered facets above); pseudonymisation is a data-model decision the scanner cannot see. Classified OOS rather than partial because a unit whose every available signal credits nothing toward it is OOS in substance — "partial" would falsely imply the engine partially evidences pseudonymisation when it evidences none. The encryption siblings are distinct measures in the same sub-paragraph and are never conflated with it.
Art. 32(2) risk-assessment: An operator-side process obligation, not infrastructure state. The engine produces configuration state, vulnerability findings, and IAM-exposure substrate that INFORM the assessment, but it cannot perform the assessment. Pair with the operator's DPIA process per Art. 35 where applicable + a privacy-GRC platform (OneTrust / TrustArc / DataGrail).

Per-sub-measure substrate walk

For each covered + partial sub-measure below, the engine produces findings the DPO / supervisory authority can attach to the Art. 32 sub-measure with a stable, supervisory-authority-grounded rationale. Patterns inherited from soc2.json's grep-verified pattern set. Evidence-gap anchors fail-close (un-enumerated region, AccessDenied, scan-time-budget exceeded) — never a false-clean.

Art. 32(1)(a) — encryption-at-rest ✓ Covered

Render personal data at rest unintelligible to unauthorised parties. Substrate: S3 server-side-encryption state; customer-managed KMS key rotation; Azure storage keySource (Microsoft-managed vs customer-managed); unresolvable-CMK detection; infrastructure double-encryption. Evidence-gap anchors fail-close (un-enumerated KMS region, missing Azure keySource property, scan-time-budget exceeded). DPA context: missing encryption-at-rest over personal data is a recurring breach-investigation finding (the British Airways / Marriott class of Art. 32 / Art. 5(1)(f) failures).

Art. 32(1)(a) — encryption-in-transit ✓ Covered

Protect personal data on the wire via enforced TLS. Substrate: RDS SSL-enforcement; Azure plaintext-HTTP (enableHttpsTrafficOnly=false); Azure minimum-TLS below the TLS1_2 baseline; weak-cipher detection via crypto_agent. Evidence-gap anchors fail-close (missing Azure HTTPS-only / minimum-TLS property; un-enumerated region). State-of-the-art (TLS 1.2+) is the baseline expectation in DPA reasoning.

Art. 32(1)(b) — confidentiality ✓ Covered

Ensure only authorised parties access personal data. Substrate: IAM shadow-admin paths; missing MFA; S3 policy-granted public access + confirmed public accessibility; anonymous public blob access (Azure); broad key-vault role grants; all-protocol 0.0.0.0/0 ingress (AWS SG + GCP firewall). Evidence-gap anchors fail-close (S3 object-ACL AccessDenied; Azure account/container enumeration incomplete). Unauthorised-access / public-exposure is the single most common breach root cause in DPA enforcement decisions.

Art. 32(1)(b) — availability ✓ Covered

Keep personal data available against accidental loss. Substrate: Azure blob soft-delete / versioning state; AWS logically air-gapped backup vaults. Evidence-gap anchors fail-close (Azure blob-service-properties unreadable; un-enumerated AWS Backup region; truncated enumeration). Accidental destruction / loss is named explicitly in Art. 32(2) as a risk to guard against; soft-delete / versioning / backup are the appropriate-to-risk availability measures.

Art. 32(1)(b) — integrity ⚠ Partial

Detect and evidence unauthorised alteration. Substrate: CloudTrail trail presence; Key Vault AuditEvent diagnostic-export. Partial because audit-trail substrate is necessary integrity-monitoring evidence but not sufficient; the operator's change-detection review, immutability (object-lock/WORM), and tamper-investigation process complete the determination. DPA context: absent/unmonitored audit trails leave alteration of personal data undetectable.

Art. 32(1)(b) — resilience ⚠ Partial

Withstand and recover from faults via redundancy. Substrate: RDS single-AZ (MultiAZ=false) detection. Partial because redundancy configuration is necessary substrate but not sufficient; the operator's DR drills, multi-region failover testing, and documented continuity process complete it. Whether single-AZ is appropriate depends on the cost of redundancy weighed against the nature/purposes of processing (Art. 32(1) chapeau).

Art. 32(1)(c) — restore-capability ⚠ Partial (Class K)

Restore availability + access in a timely manner after an incident. Substrate: DynamoDB PITR; air-gapped backup vaults; S3 lifecycle/retention. Partial (Class K) because the engine evidences the restore MECHANISM, but Art. 32(1)(c) requires restore-ABILITY, which only a successful, periodic restore TEST establishes. Backup existence is necessary but not sufficient: an untested or co-located/ransomware-encrypted backup does not satisfy (c). Art. 32(1)(c) is the ransomware-resilience article — air-gapped/immutable vaults and PITR are the appropriate-to-risk restore substrate; the operator owns restore-test cadence.

Art. 32(1)(d) — testing-effectiveness ⚠ Partial

A process for regularly testing/evaluating measure effectiveness. Substrate: GuardDuty enablement; CVE surfacing via intelligence_engine; end-of-life software detection. Partial because this recurring scan + vulnerability/threat-detection substrate is ONE input to the Art. 32(1)(d) regular-testing process; it is NOT the whole. The operator's penetration testing, DR drills, and documented test-evaluate-remediate process complete the obligation — the engine must not claim it IS the operator's regular testing. Art. 32(1)(d) is a PROCESS obligation: DPAs look for evidence of regular, documented testing + remediation, not a one-time snapshot.

Art. 32(4) — instruction-bound-processing ⚠ Partial

Persons under authority process personal data only on instructions. Substrate: IAM privilege-escalation paths; PassRole shadow-admin paths; effective kms:Decrypt on Resource:*. Partial because IAM least-privilege scoping enforces the boundary technically, but the organisational half (the Art. 28 processor agreement, documented processing instructions, personnel confidentiality undertakings) is operator-side. A person able to escalate privilege or decrypt at will can process personal data beyond instructions.

Art. 32(3) / Art. 42 certification-inheritance — provider adherence as a demonstrable-compliance ELEMENT

Article 32(3) provides that adherence to an approved code of conduct (Art. 40) or an approved certification mechanism (Art. 42) may be used as an element by which to demonstrate compliance with the Art. 32 requirements. For provider-controlled substrate (the physical and lower-stack layers of the shared-responsibility model), the cloud provider's third-party attestations are exactly such an element.

Each sub-measure in gdpr.json carries a cloudProviderAttestation block referencing, per provider:

Provider	Adherence referenced as a demonstrable-compliance element
AWS	ISO/IEC 27001 + SOC 2 + C5 (BSI) + EU Cloud Code of Conduct (Art. 40)
Microsoft Azure	ISO/IEC 27001 + SOC 2 + C5 (BSI) + EU Cloud Code of Conduct (Art. 40)
Google Cloud	ISO/IEC 27001 + SOC 2 + C5 (BSI) + EU Cloud Code of Conduct (Art. 40)

Two disciplines apply:

An element, NOT a substitute. Provider adherence is a demonstrable-compliance element for provider-controlled substrate only. It does not substitute for the operator's own appropriate measures over operator-controlled configuration (the encryption, access, and IAM choices this engine reads). The provider's C5/ISO/SOC posture does not make an operator's public bucket compliant.
Annual currency. Provider attestations are time-bounded — verify current scope + validity per service. Re-pull the current attestation at every EE release cycle and at every annual privacy-program review.

Rest-of-GDPR — OOS-by-design

Article 32 is one of 99 articles. The rest of the Regulation is operator-side legal/process discipline, OOS-by-design for any infrastructure scanner. Pair each with the named operator-side instrument:

Article(s)	Obligation	Why OOS	Operator-side pairing
Art. 6	Lawfulness of processing (lawful basis)	A legal-basis determination, not infrastructure state	Privacy-GRC (OneTrust / TrustArc / DataGrail) + legal counsel
Art. 7	Conditions for consent	Consent-capture + withdrawal records	Consent-management platform (OneTrust / TrustArc)
Arts. 12–23	Data-subject rights (access, rectification, erasure, portability, objection — DSARs)	Request-fulfilment workflow over the operator's data estate	DSAR-automation (OneTrust / DataGrail / TrustArc)
Art. 30	Records of Processing Activities (RoPA)	The processing inventory that scopes which resources hold personal data — the pairing every Art. 32 finding depends on	Privacy-GRC RoPA module (OneTrust / TrustArc / DataGrail)
Arts. 33–34	Breach notification (the 72-hour clock to the DPA; communication to data subjects)	A legal-process obligation; the engine is signal-adjacent only (it surfaces the exposure that may indicate a breach, not the notification)	Incident-response + breach-register platform + legal counsel
Art. 35	Data Protection Impact Assessment (DPIA)	A structured risk-assessment process for high-risk processing	Privacy-GRC DPIA module (OneTrust / TrustArc)
Arts. 37–39	Data Protection Officer (designation, position, tasks)	An organisational role, not infrastructure	Operator org chart + DPO-as-a-service vendor
Arts. 44–49	International transfers (adequacy, SCCs, BCRs, derogations)	A legal-transfer-mechanism determination	Transfer-impact-assessment tooling + legal counsel

This is the GDPR analog of the ISO 27001 ISMS-Clauses-4–10 OOS framing and the NIST CSF Govern-function OOS framing: the engine evidences the technical substrate; the legal/process/governance scaffolding is operator-side.

How to run an Art. 32 scan

Once the EE package is installed and your license is activated, every scan can emit GDPR Article 32 substrate by passing --compliance gdpr. The CLI's --compliance flag accepts CSV — the same finding stream feeds every framework engine in a single scan, so no re-scan is needed to add Art. 32 substrate to an existing multi-framework workflow.

# Generate a GDPR Article 32 substrate report from a fresh scan
$ nsauditor-ai scan --host aws --compliance gdpr

# Multi-framework one-scan workflow (all 7 supported frameworks at once)
$ nsauditor-ai scan --host aws \
    --compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr

# Output: reports/compliance/gdpr-<scan-id>.md + .html + .json
#   + chain-of-custody envelope + SHA-256 sidecars + RFC 3161 .tsr sidecars (if TSA configured)

Each --compliance gdpr run writes a per-sub-measure Art. 32 report (cover-page Scope Attestation, per-sub-measure status with Art. 32 rule-text citations + proportionality factors + personal-data-scope caveat + Art. 83(4) tier note), plus the machine-readable JSON suitable for privacy-GRC ingestion. All artifacts ship with a .sha256 integrity sidecar and can run side-by-side with the other six framework packs.

Zero Data Exfiltration — no new processor under Art. 28

NSAuditor AI EE inherits the same Zero Data Exfiltration architecture across all seven supported frameworks:

Local-only scanning — no scan data leaves the operator's environment; no SaaS dependency.
Local-only AI — Claude API integration is OPTIONAL (operator-configured); air-gapped fallback for restricted-data scope.
Operator-controlled signing — TSA configuration + Ed25519 suppression signing operator-side.
Chain-of-custody manifest — SHA-256 sidecars + RFC 3161 trusted-timestamps + envelope artifact integrity verification.
Configurable scope — operator excludes targets via CLI; scope-attestation cover page documents exclusions + justifications.

This architecture is institutionally critical under GDPR because a SaaS compliance tool that ingests scan data into a third-party cloud environment introduces a new processor (Art. 28) — and, where personal data is involved, a new processing activity that the operator's RoPA (Art. 30) and DPA chain must address, plus a potential international-transfer (Arts. 44–49) consideration if that processor operates outside the EEA. Zero Data Exfiltration sidesteps that processor expansion entirely — the scan substrate never becomes someone else's processing operation.

Auditor / DPA FAQ

Is this GDPR compliance? (No — Article 32 substrate only.)

No. This is NOT GDPR compliance and there is no GDPR certificate under the Regulation. NSAuditor produces infrastructure-substrate evidence for the technical facets of Article 32 only — one article of a 99-article legal regime. Every other article is operator-side and OOS-by-design. This report is input to your Art. 32 measures, not a whole-of-Regulation attestation.

Is an unencrypted bucket automatically an Article 32 violation?

No. Art. 32 applies to the security of processing of personal data. The scanner reads infrastructure state but cannot determine which resources actually hold personal data. An unencrypted bucket is an Art. 32 finding only if it holds personal data. Pair every finding with your Art. 30 RoPA to confirm the resource is in-scope first.

What fine tier do Article 32 infringements fall under?

The lower Art. 83(4) tier — up to €10 million OR 2% of total worldwide annual turnover, whichever is higher. The famous €20M / 4% headline is the Art. 83(5) HIGHER tier (basic principles, data-subject rights, international transfers) and does not apply to Art. 32. Quoting the headline number against an Art. 32 finding is itself an overclaim.

Is the engine an absolute pass/fail verdict for Article 32?

No. Art. 32(1) measures are explicitly proportionate — "appropriate to the risk." The chapeau names four factors (state of the art, cost of implementation, nature/scope/context/purposes, risk to data subjects) the operator must weigh. The engine produces substrate FOR that appropriateness determination; it does not make it.

Can NSAuditor perform the Art. 32(2) risk assessment?

No. Art. 32(2) is an operator-side risk-assessment process — the GDPR analog of the HIPAA §164.308(a)(1)(ii)(A) Risk Analysis. The engine produces substrate that INFORMS it; it cannot perform it. Pair with your DPIA process (Art. 35) and a privacy-GRC platform (OneTrust / TrustArc / DataGrail).

How does cloud-provider ISO 27001 / SOC 2 / C5 adherence count?

Art. 32(3) allows adherence to an approved code of conduct (Art. 40) or certification mechanism (Art. 42) to be used as an element to demonstrate compliance — not a substitute. It applies to provider-controlled substrate only and does not make the operator's public bucket compliant. Attestations are annual-currency: re-verify scope and validity each release cycle.

Why is pseudonymisation out of scope when Art. 32(1)(a) names it?

Art. 32(1)(a) names BOTH pseudonymisation and encryption. Encryption is substrate-rich (the two covered facets); pseudonymisation is a data-model decision the scanner cannot see. A unit whose every available signal credits nothing toward it is OOS in substance — calling it "partial" would falsely imply partial evidence where there is none. The encryption siblings are distinct measures in the same sub-paragraph and are never conflated with it.

Does this replace OneTrust / TrustArc / DataGrail?

No — it complements them. NSAuditor handles the Art. 32 technical-substrate dimension (per-sub-measure configuration evidence + signed artifacts); the privacy-GRC platform handles RoPA + DSARs + consent + DPIA + breach register + the rest of the 99 articles. NSAuditor + a privacy-GRC platform = a complete Article 32 program inside a complete GDPR program. Neither tool, standalone, is GDPR coverage.