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. SHA-256 chain-of-custody sidecars, cover-page Scope Attestation, four-factor proportionality discipline, Art. 83(4) lower-tier fine framing — and Zero Data Exfiltration: no scan data or evidence artifact is ever transmitted to Nsasoft, and every outbound path the product can take is enumerated in its published egress register. This is Art. 32 substrate only: it is not GDPR compliance, and no GDPR certificate exists under the Regulation.
LATEST · EE 0.42.0 · 2026-08-27 eighth framework — NIST SP 800-171 Rev 2 GDPR Article 32 (Security of Processing)
EE 0.42.0 (2026-08-27) is the current release — partition-correct AWS auditing (GovCloud / China / ISO / European Sovereign Cloud) and fail-closed Azure sovereign-cloud selection with an estate stamp; all eight coverage matrices unchanged. Prior: EE 0.41.0 (2026-08-26) — the 29th Enterprise plugin, a dedicated Amazon DocumentDB auditor (plugin 1230), owns the docdb engine on the shared RDS control plane, where a DocumentDB cluster’s storage-encryption gap could previously read clean under the RDS auditor’s Aurora-only filter; the RDS auditor now engine-filters DocumentDB and Neptune with a standing disclosure that a Neptune estate is unaudited. Plugin count 28→29 (29 Enterprise auditors, 56 overall), and all eight coverage matrices are unchanged. Prior: EE 0.40.3 (2026-08-25) was a focused evidence-integrity patch, and the headline of the 0.40 line remained the eighth compliance framework, NIST SP 800-171 Rev 2, and it routes from the same single read-only scan as the other seven. Every mapped requirement carries the full list of its SP 800-171A determination statements alongside the 69 of 172 this engine supplies examine-method material for — so a C3PAO reads exactly which objectives your configuration already evidences. That is coverage claimed at the level an assessment is actually scored at. All 110 Rev 2 requirements are enumerated with no declared subset, and Rev 2 is pinned deliberately, because CMMC assesses Rev 2 by rule. Scoped as evidence substrate for CMMC Level 2 preparation: it feeds your System Security Plan and POA&M and leaves the determination where it belongs, with your assessor. The seven existing coverage matrices are unchanged and the plugin catalog is unchanged at 28 Enterprise auditors (55 overall). Read the NIST SP 800-171 Rev 2 coverage page →
Prior: EE 0.39.0 (2026-08-19) — every cloud provider now tells you what it did not look at. A scanner that finds nothing has said two different things at once: we looked and it was clean, and we never looked. A deferredScope declaration separates them — a static, per-plugin statement of what the release does not assess. Seven new declarations ship across the GCP and Azure plugins, 8 to 12 boundaries each, emitted at run scope on the audited path including over an empty estate, which is the case that matters most: an account with no resources produces zero findings whether or not anything was ever examined. Re-measured on this release against real cloud accounts — AWS reports 9 declarations, Azure 4, GCP 3 — and two AWS declarations became estate-independent, so the count no longer scales with the number of enabled regions. A declaration routes to zero controls by design, so the GDPR Article 32 matrix is unchanged at 4 covered / 5 partial / 2 out-of-scope: a disclosure that a surface was not examined is never filed as evidence that it passed.
Prior — EE 0.37.0 (2026-08-16) carried vulnerability data onto a network that has no way to fetch it. nsauditor-ai feed bundle merges the NVD feed files you downloaded on a connected host into one portable archive; feed import reads it into the offline CVE store on the far side and names why it skipped records — withdrawn CVEs and entries with no CPE data are expected, and are not data loss. Optional --kev / --epss carry your own CISA KEV and FIRST EPSS downloads inside the same archive, validated on the connected host where a bad file can still be replaced — no exploit data ships with this product. Each carried file records a SHA-256 that import verifies, so a file altered in transit is detected. Air-gapped delivery now ships as a dependency-complete bundle with an install script and checksums — restricted distribution; its install script is verified on native aarch64 as well as amd64, so an arm64 enclave is covered. (The published container image is amd64.) EE 0.42.0 requires CE ≥ 0.2.49 — RAISED at 0.42.0, because on an older Community Edition the ISO/EUSC partition fix is inert rather than absent; paired CE 0.2.49 + agent-skill 0.2.47. EE 0.37.0 needed CE ≥ 0.2.42, raised at that release, because the feed commands are routed from Community Edition.
Prior — EE 0.36.0 (2026-08-13) — the verification release. A compliance report now cryptographically checks the suppression signatures it renders, for approvers whose registry entry carries key material, and the verdict names the exact signature bytes it checked — which is the difference between telling a DPO that an accepted risk was approved by a named person and being able to show which bytes carry that approval. Two axes, not one. verified answers whether the suppression should stand and cryptoValid answers whether those bytes came from the named key; they diverge on a revoked key, which is what makes signing after revocation a cryptographic finding rather than an operator-editable string. A tampered record renders “signature FAILED verification”. The condition is stated because it is load-bearing: every identity registry in the field today is fingerprint-only, so a missing verdict means NOT CHECKED and never FAILED — the report says “signed — not checked by this report”, and a report advisory names how many registered approvers are still awaiting material and what to paste. An engine fault in the identity phase now fails that framework’s report loudly instead of rendering a degraded section that told the reader to restore a registry that was fine — a disclosed failure attributed to the wrong party is not a disclosure, which matters most where the reader is a DPO or a supervisory authority. EE 0.36.0 requires CE ≥ 0.2.40, unchanged from the previous release, because nothing in this cycle needs new Community Edition code. Matrix-neutral — all seven coverage matrices UNCHANGED and the plugin count UNCHANGED at 28 Enterprise plugins (27 of them cloud auditors), 55 overall. The GDPR Art. 32 substrate matrix is UNCHANGED at 4 covered / 5 partial / 2 OOS. Paired CE 0.2.41 + agent-skill 0.2.39. This remains GDPR Article 32 (Security of Processing) infrastructure substrate only, not GDPR compliance.
Earlier in the same lane: EE 0.33.1 (2026-08-07) — auditor-verifiable proof, now stated in every framework report. All seven auditor-shaped reports now say the same thing about evidence integrity: RFC 3161 trusted timestamping is opt-in via NSAUDITOR_TSA_URL, pointed at a Time-Stamp Authority you choose, and every compliance artifact then carries a .tsr sidecar your auditor verifies offline with stock openssl — against that third party, with none of our software in the path. Opt-in with no default, ever, so an air-gapped environment simply leaves it unset. Verified end to end on 2026-08-07 against a real public Time-Stamp Authority through the published binaries. The agent skill and the Community Edition README answer the same way, so every surface a reader can reach agrees. It builds directly on EE 0.33.0 (2026-08-07), the wiring release. Eleven compliance options that nothing shipped could populate now receive values from a real entry point: the option existed, the engine read it, and no entry point ever wrote to it. The new entry points live in Community Edition, so EE 0.33.0 requires CE ≥ 0.2.37 — on an older CE the options stay unfed. Zero Data Exfiltration is now a positive register of 17 enumerated outbound paths, each named with its trigger and its off switch, rather than a blanket denial — which is what a DPO assessing whether the tool introduces a new processor under Art. 28 actually needs to read. RFC 3161 trusted timestamping is now opt-in via NSAUDITOR_TSA_URL and was verified against a real timestamp authority on 2026-08-07 — opt-in, not a default, and it is itself one of those enumerated outbound paths, so enabling it is a deliberate decision with an Art. 32 consequence. Ed25519 suppression signing was reachable but unproven at that release, and its verification gate has since run against published bytes, for approvers whose registry entry carries key material — compliance suppress signs the approval it writes when NSAUDITOR_SIGNING_KEY names a local signing key, and EE 0.36.0 is the half that reads that approval back. EE 0.35.0 required CE ≥ 0.2.40, because the approval commands live in the Community Edition and forward to Enterprise. Signature records now carry algorithm and backend frozen at the moment of signing rather than re-derived later. Matrix-neutral — all seven coverage matrices UNCHANGED and the plugin count UNCHANGED at 28 Enterprise plugins (27 of them cloud auditors), 55 overall. The GDPR Art. 32 substrate matrix is UNCHANGED at 4 covered / 5 partial / 2 OOS. Paired CE 0.2.37 + agent-skill 0.2.35. This remains GDPR Article 32 (Security of Processing) infrastructure substrate only, not GDPR compliance.
Prior: EE 0.32.11 (2026-08-05) — the release gate that is supposed to tell us what a customer actually installs had been auditing the maintainer’s development tree and calling it the production closure. It now packs the tarball, installs it the way a customer does, and audits THAT — and it refuses to report clean until it has proved an advisory database actually answered. The difference is not a rounding error. The development tree carries 25 advisories, 8 of them HIGH; the closure a customer installs carries 6, none HIGH. Across 26 advisory packages the two lists share five — and zero high-severity ones. Every one of those eight highs was development-only. Art. 32(1) asks for measures appropriate to the risk taking into account the state of the art, and the state of a processor’s own tooling is part of what a DPO or supervisory authority may reasonably ask about: a gate reading the wrong tree does not produce an obviously wrong number, it produces a number that reads exactly like the right one. Also in this release — the SOC 2 matrix is now enumerated in full at 10 covered / 4 partial / 37 out of scope = 51, the complete AICPA TSC 2017 universe; that is enumeration completeness, not a coverage change, and no control changed status and no routing changed. The Type I vs Type II documentation now says, mechanism by mechanism, which parts are reachable from a shipped entry point and which are not. Verified on the published bytes, not the source tree: after a global install of the published tarballs, 28 of 28 Enterprise plugins active, and a three-cloud scan produced a 76-file evidence pack per cloud. That release was matrix-neutral — still 28 Enterprise plugins, 27 of them cloud auditors (55 overall), seven frameworks, and the other six coverage matrices unchanged. The GDPR Art. 32 substrate matrix is UNCHANGED at 4 covered / 5 partial / 2 OOS. Paired CE 0.2.35 + agent-skill 0.2.33. This remains GDPR Article 32 (Security of Processing) infrastructure substrate only, not GDPR compliance.
Prior: EE 0.32.9 (2026-07-29) — an internal-provenance strip plus a false-clean closure. An Article 32 substrate report is a document a controller or processor hands its DPO, its auditor, or a supervisory authority, and ours carried internal engineering identifiers — roadmap ids, internal release stamps, the name of an internal audit review — in finding titles, on the attestation cover page and in the chain-of-custody record. Measured on a rebuilt three-cloud evidence pack: 686 unexplained internal-marker occurrences → 0 across 105 files, with a positive control in the same run (3,572 benign matches still detected) so the zero is a measurement rather than an absence of looking. The false-clean closure — when a cloud plugin could not start (optional SDK absent, credentials unusable) it refused to report, and that refusal evaporated one layer up: the compliance report came out byte-identical to one where the scanner ran and found nothing. Ten controls read PASS — no violation, no warning. The dangerous shape is ordinary: AWS and GCP scan for real, Azure’s SDK is absent, and the combined pack reads as a clean three-cloud audit. Now every in-scope sub-measure of a cloud that could not be scanned carries a fail-closed evidence gap — which is the honest input to an Art. 32(1) appropriateness determination, since an unscannable cloud is unevidenced substrate, not evidence of an appropriate measure. Also in that release — an archived scan re-processed by the new build WARNS instead of failing clean; four report surfaces that contradicted each other on trusted timestamping — which was still on the roadmap at that release, and became opt-in via NSAUDITOR_TSA_URL as of EE 0.33.0 — now say the same verifiable thing; and a new instrument, a pack scanner that FAILS CLOSED when its own positive control is empty. The paired Community Edition fixes --out <dir>, which wrote to the PARENT directory when the directory name contained a dot; the MCP scan_cloud summary now handles both spellings of the evidence-gap prefix; and validate no longer misreports where plugins came from. Two upgrade notes still apply: (1) the evidence-gap finding TITLE changed at 0.32.9, so suppression rules matching the older text stop matching — the direction is safe (findings resurface rather than hide) but it is SILENT; (2) re-scan rather than re-process scans captured before 0.32.9, as the engine now warns. That release was matrix-neutral too — 28 Enterprise plugins, 27 of them cloud auditors, seven frameworks, and all seven coverage matrices unchanged. Paired CE 0.2.34 + agent-skill 0.2.32. This remains GDPR Article 32 (Security of Processing) infrastructure substrate only, not GDPR compliance.
Before that: EE 0.32.8 (2026-07-28) — capability-claim honesty pass, part 2 — the air-gapped-delivery class. 27 advertised claims across the three published packages were checked against the code and withdrawn: an arm64 image (the build forces linux/amd64), offline-installable tarballs, monthly NVD feed bundles, an air-gapped install script, and a feed import CLI command with no implementation. Since earned back and now shipping: the air-gapped install script and the dependency-complete offline bundle, and the feed import command (with feed bundle), all at EE 0.37.0. Only the arm64 container image remains unpublished — the bundle itself is verified on native aarch64 as well as amd64. Five of the 27 were not documentation but rendered runtime strings — the [COVERAGE GAP] rationale that prints verbatim into the assessor-facing evidence pack was telling the reader to import a feed with a command that does not exist. Nothing was withdrawn by deletion: the air-gap story was rewritten to what the code supports — a linux/amd64 delivery image or npm host install, fully offline ES256 license verification with no phone-home, and offline CVE matching under NSAUDITOR_OFFLINE_ONLY=1 — and ends with an explicit “deliberately not claimed” list, held by two mutation-proven guards. Matrix-neutral — no detection, routing or coverage change; still 28 EE plugins and all seven coverage matrices byte-identical to 0.32.7. The GDPR Art. 32 substrate matrix is UNCHANGED at 4 covered / 5 partial / 2 OOS. The paired Community Edition also fixes --out, which silently wrote to the parent directory when the output directory was version-named. Regression 10,956 pass / 0 fail. Paired CE 0.2.33 + agent-skill 0.2.31. The Vanta · Drata · Secureframe GRC connectors ship as before (opt-in, outbound, single-workspace, early-access). And before that: EE 0.32.7 (2026-07-21) — cross-framework routing, so network-scan findings reach every framework that maps their control subject; matrix-neutral. This is GDPR Article 32 infrastructure substrate only, not GDPR compliance.
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 hash-chained evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, and a documented suppression workflow — 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:
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 seven frameworks. Neither tool, standalone, is GDPR coverage — and this page never claims the engine is.
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.
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:
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.
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.
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).
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.)
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 — 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.
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.
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).
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.
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). Over-broad KMS decrypt grants and anonymous SQS/SNS read grants also route to Art. 32(1)(b)-confidentiality as substrate findings (the matrix stays 4 / 5 / 2; send/delete-only grants are not confidentiality concerns). 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.
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.
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.
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).
Restore availability + access in a timely manner after an incident. Substrate: DynamoDB PITR; air-gapped backup vaults; S3 lifecycle/retention. Partial 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.
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.
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.
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:
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.
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.
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 seven framework packs.
NSAuditor AI EE inherits the same Zero Data Exfiltration architecture across all eight supported frameworks:
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.
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.
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.
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.
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.
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).
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.
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.
No — it complements them. NSAuditor handles the Art. 32 technical-substrate dimension (per-sub-measure configuration evidence + SHA-256 chain-of-custody); 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.