SOC2) - Audit Trail Platform (ATP)¶

ATP ensures verifiable compliance with global privacy regulations — designed for transparency, accountability, and data subject rights.

Purpose & Scope¶

Detailed compliance mapping for GDPR, HIPAA, and SOC 2 Trust Services Criteria.
ATP-specific controls, evidence artifacts, and verification procedures per framework.
Data subject rights workflows (DSAR, access, rectification, erasure, portability).
Cross-references to technical implementation in other Platform/Hardening docs.

What this document establishes

The privacy-by-design posture for ATP and how it is realized in code, configuration, and process.
A canonical mapping from regulatory requirements → concrete ATP controls → auditable evidence.
Standard operating procedures for DSAR handling, breach communication, and cross-border transfer reviews.

Scope boundaries

In-scope: audit evidence processed by ATP services, meta-audit of platform operations, tenant-facing exports, and operator workflows.
Out-of-scope: tenants’ own application privacy programs, non-ATP systems, and customer-specific contractual variations (referenced as CUECs in SOC 2).

Roles & responsibilities

Product/Engineering: implement and maintain controls; supply technical evidence.
Security/DPO: interpret regulations, approve policy changes, manage DPIA/ROPA, oversee DSARs.
SRE/Operations: ensure monitoring, backups/restore, incident handling, and evidence retention.

Primary artifacts (evidence)

Policies/procedures (privacy, retention, incident response), ROPA, DPIA, BAAs/DPAs/SCCs.
Control test results and dashboards (encryption coverage, retention compliance, DSAR SLAs).
Signed export manifests, integrity proofs, and immutable audit records.

Cross-references

security-compliance.md — security control framework, incident response, monitoring
data-residency-retention.md — residency enforcement, retention/purge, legal holds
pii-redaction-classification.md — classification taxonomy, redaction strategies, policy-as-code

Privacy-by-Design Principles¶

Data minimization — Collect and persist only what is necessary for auditability. Default to classified inputs and redacted storage/reads; prefer fingerprints/tokens over raw values.
Implemented via: ingestion guards, write/read redactors, schema contracts with “required vs optional” fields.
Purpose limitation — Use audit data solely for accountability, security, and compliance scenarios defined by tenants and ATP policies; no secondary profiling or marketing use.
Implemented via: policy-as-code purpose tags, ABAC checks on purpose, export guardrails, contractually in DPAs/BAAs.
Transparency — Clearly document what ATP logs, why, and for how long; expose tenant-facing ROPA entries and export manifests that include policy versions and residency.
Implemented via: signed manifest on exports, documentation pages, portal summaries per tenant/region.
Accountability — Every control decision is provable with immutable meta-audit entries (who/what/when/why). Regular attestations and evidence bundles maintained for auditors.
Implemented via: meta-audit stream, periodic reports, control dashboards, ADR-driven changes.
Security — Encrypt everywhere, enforce least-privilege, verify integrity continuously; treat privacy as a security outcome.
Implemented via: per-tenant keys (KMS/HSM), RBAC+ABAC, tamper-evident chains, secure exports.
See also: platform/security-compliance.md.

Design patterns (how this shows up in code & ops)¶

Default-deny with policy-as-code — Requests without explicit policy allowance are denied; policies versioned, signed, and rolled out atomically.
Minimize at source — Producers attach hints; ingestion upgrades classification and drops credentials by default.
Immutable by default — Rectifications append corrective records; deletes occur only post-retention or per lawful request with evidence.
Separation of duties — Data handlers, key custodians, and approvers are distinct; sensitive routes require dual-control.
Residency-first routing — All processing stays in-region unless an approved break-glass route is in effect.

Evidence & checks (auditor-ready)¶

Policy bundle signatures, rollout logs, and effective policy version in export manifests.
ROPA/DPIA documents linked to services and data categories.
Meta-audit samples proving purpose tags, ABAC decisions, and redaction outcomes.
Residency placement metrics and retention/purge execution logs.

Cross-references

pii-redaction-classification.md · data-residency-retention.md · security-compliance.md

Regulation scope — Applies to personal data of EU/EEA residents processed by ATP, regardless of where ATP is hosted or operated (territorial scope via offering/monitoring criteria).
ATP role — ATP processes audit records on behalf of tenants (tenants are Controllers; ATP is Processor; cloud/IaaS vendors are Sub-processors). ATP may act as Controller for limited platform telemetry and support logs; these are segregated and documented in ROPA.
Legal basis — Processing is justified under tenant contracts for legitimate interests (security/accountability) and/or legal obligation where applicable. ATP, as Processor, relies on DPA terms with tenants; tenant determines the lawful basis for its inputs. Sub-processor terms (e.g., cloud providers) are covered by ATP’s DPA/SCCs.
Key articles addressed
- Art. 5: principles (lawfulness, minimization, storage limitation, integrity, accountability).
- Art. 15–22: data subject rights (access, rectification, erasure, portability, objection).
- Art. 25: privacy by design/default (classification, redaction, least privilege).
- Art. 30: records of processing (ROPA maintained for ATP operations).
- Art. 32: security of processing (encryption, access controls, integrity).
- Art. 33–34: breach notification (DPA/data subject notices, timelines).

Processor governance: DPAs with tenants; sub-processor register + SCCs/TIAs for cross-border flows.
Privacy by design: classification+redaction at write/read; purpose-tagged queries; immutable meta-audit.
Residency & transfers: region-pinned storage, controlled failover, export routes with policy approval.
Storage limitation: policy-driven retention, legal holds, evidenced purges.
Security of processing: per-tenant keys, ABAC, tamper-evidence, continuous monitoring.
DSAR & rights: portal/API workflows; rectification via corrective append; erasure post-retention or via pseudonymization where lawful.

Evidence artifacts (auditor-ready)¶

Executed DPA (with SCCs/TIA where relevant), ROPA entries, privacy policy.
Control dashboards (encryption coverage, residency placement), retention/purge logs.
DSAR case records (requests, identity verification, responses, manifests).

Cross-references

platform/security-compliance.md · platform/data-residency-retention.md · platform/pii-redaction-classification.md · platform/privacy-gdpr-hipaa-soc2.md#appendix-a-—-gdpr-article-mapping-quick-reference

Goal: Ensure every processing activity is lawful, expected, and clearly explained — and that proof of each is continuously available.

Lawfulness¶

Per-tenant lawful basis registry
Each tenant declares the lawful basis per stream/purpose (e.g., security audit, fraud detection) in the DPA addendum. Typical bases: Legitimate Interest (Art. 6(1)(f)) or Legal Obligation (Art. 6(1)©).
Policy-as-code enforcement
Ingestion requires purpose and lawfulBasis tags; missing/unknown pairs are blocked (4xx) and logged in the meta-audit stream. Runtime policy validates that declared purposes match the tenant’s registry.
Special categories / PHI
Streams containing health or other special categories require explicit contractual scopes (e.g., BAA) and stricter redaction/tokenization.

Example — Lawful Basis Registry (excerpt)

Tenant	Stream	Purpose	Lawful Basis	Notes
ACME	`auth.login.audit`	Security & audit	Legitimate Interest	Controller determines LI
ACME	`billing.events`	Compliance records	Legal Obligation	Tax/compliance retention
MedCo	`ehr.access.audit`	HIPAA accountability	Contractual/BAA scope	PHI; stricter controls

Fairness¶

No hidden collection
ATP only processes events explicitly routed to the platform via documented producers/SDKs. Shadow or undisclosed collection is prohibited.
Scope control
Field allowlists and schema contracts prevent excessive capture. Producers must not include out-of-scope attributes (blocked by ingestion guards).
Tenant alignment
Tenants attest to their own privacy notices matching ATP’s processing scope (CUEC; verified during onboarding and annually).

Transparency¶

Public documentation
A platform privacy page describes what ATP logs, why, and for how long, including links to residency/retention and redaction policies.
Data subject comms
DSAR responses include signed manifests listing data categories, purposes, policy versions, residency, and retention states.
Change logs
Material changes to processing are versioned (ADR + policy bundle) and reflected in the privacy page with effective dates.

Privacy Notice (excerpt template)

We process audit evidence (event metadata, security-related identifiers) for the purposes of security and accountability. Processing is performed by our audit provider (ATP) as a processor under contract. Data are stored in-region per residency rules and retained according to contractual retention periods. Sensitive values are redacted or tokenized by default.

Evidence (auditor-ready)¶

Executed DPA(s) with lawful-basis annex, ROPA entries for ATP Processor activities.
Policy bundles (purpose ↔ basis mappings), meta-audit logs of denied/approved decisions.
Public privacy notice and change history; DSAR manifests showing purposes and policy versions.

Validation & monitoring¶

CI linter on policy bundles: every stream must have a declared purpose and basis.
Runtime metrics: purpose.basis.denied.count, unknown.purpose.count, policy.version.skew.
Quarterly review: sample 1% of streams per tenant for basis/purpose correctness; record findings.

Cross-references

security-compliance.md · data-residency-retention.md · pii-redaction-classification.md · privacy-gdpr-hipaa-soc2.md#appendix-a-—-gdpr-article-mapping-quick-reference

Goal: Provide verifiable, tenant-scoped workflows for all applicable GDPR rights with clear SLAs, identity verification, and immutable evidence.

Right of Access (Art. 15)¶

Workflow
1. Verify identity of the requester (tenant-managed KYC or ATP verification flow).
2. Build a SubjectSelector from normalized identifiers (e.g., email, phone E.164, tenant user ID) and their tenant-salted hashes to match both raw and hashed fields.
3. Execute tenant-scoped queries (region-aware) across streams and time ranges.
4. Produce a DSAR export: structured JSON/CSV/Parquet + a signed manifest (counts, policy versions, residency, policy digests).
5. Deliver via secure download (time-bound URL) or tenant-controlled storage.
Response window: within 30 days (with up to +60 days extension for complexity; extension reason recorded).
Implementation anchors: guides/export-and-ediscovery.md (export orchestrator), Query APIs with subject filters, platform/pii-redaction-classification.md (read-time redaction).
Manifest (example)

{
"tenantId": "t-123",
"subject": {"email":"john.doe@example.com"},
"policyVersion": "policy-atp-v1#1",
"residency": "EU",
"records": 1287,
"hashes": {"segmentRoot":"b8d1..."},
"generatedAtUtc": "2025-10-30T10:00:00Z",
"signature": "MEQCIF..."
}

Right to Rectification (Art. 16)¶

Immutability constraint: Original audit records are not altered.
Correction method
- Append a corrective AuditRecord linking to the original (corrects: <recordId>), include corrected values and justification.
- Query and export layers resolve to the latest corrective state while preserving history.
Evidence
- Correction ticket (request, verification), corrective record ID, meta-audit entry with who/when/why.

Right to Erasure (Art. 17)¶

Constraints
- Where ATP serves legal/contractual audit obligations, erasure may be deferred until the retention period expires.
- Legal holds suspend deletion for the scoped window.
When lawful
- Apply pseudonymization/redaction immediately (e.g., remove direct identifiers), mark for post-retention physical purge.
- On eligibility, purge eligible segments and emit PurgeAttestation (signed).
Outcomes
- Fulfilled (pseudonymized now, deleted at retention end),
- Deferred (retention/hold),
- Denied (documented legal basis).
Evidence
- Erasure decision log (reason codes), retention policy refs, legal hold records, purge attestations.
Alignment
- platform/data-residency-retention.md §6–8 (retention, legal hold, purge).

Right to Data Portability (Art. 20)¶

Formats: Parquet, NDJSON, CSV (UTF-8), with schema definitions and signed manifests.
Scope: Data provided by the subject and data observed/derived relating to the subject (within ATP’s audit remit).
Delivery: Secure, time-bound download or handoff to tenant bucket (private link), with watermarking where appropriate.
Evidence: Export job log, manifest signature, delivery receipt.

Right to Object (Art. 21)¶

Applicability
- If tenant’s legal basis is Legitimate Interest, subjects may object to non-essential logging.
- If logging is Legal Obligation or strictly necessary for security, objection may be denied with rationale.
Handling
- Register a Subject Suppression for non-essential streams; enforce at ingestion guards (drop/transform) and producer guidance.
- Document decision, purpose analysis, and tenant notice.
Evidence
- Suppression registry entry, policy evaluation logs, meta-audit of denied/approved events.

Shared controls (applies to all rights)¶

Identity verification: Mandatory before disclosure or change; verification evidence attached to the case.
SLA tracking: Timer starts at validated request; reminders and escalation paths (DPO/legal) tracked.
Redaction: Exports and views apply role-based redaction per platform/pii-redaction-classification.md.
Residency: All processing and exports are region-pinned per platform/data-residency-retention.md.

Metrics & SLAs¶

dsar.requests.total, dsar.requests.byRight{access|rectification|erasure|portability|objection}
dsar.sla.on_time.rate (target ≥ 95%), dsar.avg.response.days (target < 25)
erasure.deferred.count (breakdown by reason), suppression.active.count

Cross-references

guides/export-and-ediscovery.md · platform/pii-redaction-classification.md · platform/data-residency-retention.md · platform/security-compliance.md

Goal: Keep personal data only as long as necessary for declared purposes and legal obligations — and prove enforcement with immutable evidence.

Retention policy¶

Default: 7 years for audit evidence. Tenants can configure within bounds (e.g., min 1 year, max 10 years) by contract and jurisdiction.
Scope: Policies apply per tenant → stream → region and are versioned (policy-as-code). Historical policies are retained for replay.
Clock: Countdown based on eventTime (preferred) or ingestedAt fallback — source recorded in metadata.

Edition guidance (example)

Edition	Default	Bounds	Notes
Free	3 years	1–5y	Cost-conscious; aggressive purges
Business	7 years	1–10y	Standard compliance window
Enterprise	7 years	1–10y	Per-stream overrides + legal hold API

Automated purge workflows¶

Eligibility: now ≥ eventTime + retention AND no active legalHold or regulatorHold AND residency/export constraints satisfied.
WORM model: Append-only; purge = irreversible physical removal of eligible segments with index compaction.
Export-before-delete (optional): Emit a signed manifest (checksums, counts, policy version) to tenant-controlled storage before deletion.
Evidence trail: Each purge emits:
- PurgeRequest (window, selectors, policy digest),
- PurgeResult (counts, hashes, segment IDs),
- PurgeAttestation (signatures, operator/bot identity).

Workflow summary

1) Build candidate set (tenantId, stream, region, time-window)
2) Evaluate holds/exceptions → remove blocked items
3) (Optional) Export + sign manifest
4) Delete segments + compact indexes
5) Emit attestations to meta-audit and update dashboards

Legal holds & overrides¶

Precedence: Active holds suspend purges for their scope (tenant/stream/time-range).
Release: Dual-control release only; actions fully meta-audited.
Regulatory extensions: Retention extended with reason codes; recorded in hold registry.

Verification & reporting¶

Controls
- Scheduled dry-run purges (no delete) with scope statistics.
- Residency-aware execution: deletes performed in-region; cross-region requires policy approval.
- Tamper-evidence: Re-verify segment hashes pre-delete; chain manifests to integrity anchors.
Metrics/SLOs
- retention.purge.eligible.count, retention.purge.deleted.count
- hold.blocked.count (by reason), purge.attestation.signed.count
- SLO: ≥ 99% of eligible records purged within 7 days of eligibility.

Evidence (auditor-ready)¶

Retention policy bundle (version + bounds), PurgeAttestation records with signatures,
Dry-run reports, deletion logs (segment IDs + checksum diffs),
Hold registry extracts (active/released) with approver identities.

Alignment & cross-references

platform/data-residency-retention.md §6–8 · platform/security-compliance.md · platform/pii-redaction-classification.md

Goal: Keep EU/EEA personal data in-region by default; if a transfer is strictly necessary, apply GDPR-compliant safeguards, document the rationale, and prove continuous enforcement.

Residency enforcement (design-time & run-time)¶

Region pinning — Each tenant has a mandatory RegionCode (e.g., EU) and DataSiloId. All write paths (ingestion, projections, indexes) are regionalized; processing executes in-region.
Policy-as-code — ABAC/OPA rules deny cross-region reads/writes unless a transfer policy is explicitly approved. Tokens carry residency claims; services enforce on every request.
Network boundaries — Private endpoints, VNet peering, and egress allowlists (no arbitrary outbound). Cross-region links disabled for data planes unless a policy grants a temporary, scoped exception.
Operational guardrails — Residency controls covered by CI/CD checks (deployment in wrong region is blocked) and runtime placement checks (mismatch emits ResidencyViolation with auto-quarantine).

Cross-border safeguards (when transfer is necessary)¶

Default posture — No transfer. Prefer local processing and regional exports to tenant-controlled storage in-region.
Legal mechanisms — If transfer is necessary:
- Adequacy decision (Art. 45) → proceed per DPA with documentation.
- SCCs (EU 2021/914) Module ⅔ + Transfer Impact Assessment (TIA) (Art. 46) → implement supplementary measures:
  - Strong encryption with region-held keys (KMS/HSM); no key material leaves region.
  - Pseudonymization of identifiers before transfer; re-identification only in-region.
  - Access controls (need-to-know), logging, and contractual restrictions with subprocessors.
Documentation — Maintain a Subprocessor Register, executed SCCs/DPAs, and completed TIAs; link all to the tenant contract profile.

Transfer decision matrix (summary)

Scenario	Mechanism	Supplementary Measures	Allowed?
EEA → Adequate country	Adequacy + DPA	Standard ATP security	✅
EEA → Non-adequate	SCCs + TIA	Region-held keys, pseudonymization, ABAC, logs	✅ (with safeguards)
EEA → Non-adequate, keys hosted outside EEA	—	—	❌ Block (no feasible safeguards)

Failover constraints (resiliency with residency)¶

Read-only failover — If regional service disruption requires activation in a non-EEA region, ATP enters read-only mode for affected tenants; writes are blocked until primary region is restored or a break-glass exception is approved.
Break-glass governance — Temporary cross-region writes require DPO/legal approval, time-bound scopes, and enhanced logging; post-incident data repatriation and attestation are mandatory.
Drills — Scheduled DR tests validate that read-only failover preserves residency constraints and that metrics/alerts fire correctly.

Evidence (auditor-ready)¶

Residency policy bundle (OPA/Rego) with effective version and rollout logs.
Placement reports (per tenant/stream/region), ResidencyViolation alerts, and remediation records.
Executed SCCs/DPAs, TIAs, and the Subprocessor Register entries.
DR/failover test reports demonstrating read-only posture outside the primary region.

Alignment & cross-references
platform/data-residency-retention.md §2–4, §21 · platform/security-compliance.md · platform/pii-redaction-classification.md

Example — Residency policy excerpt (YAML)

residency:
  defaultRegion: EU
  enforceAt:
    - ingestion
    - query
    - export
  crossBorder:
    allowed: false
    exceptions:
      - id: dr-readonly
        mode: readOnly
        expiresUtc: 2025-12-31T23:59:59Z
        approvals: [DPO, Legal]
        safeguards:
          - regionHeldKeys
          - pseudonymizeIdentifiers
          - enhancedLogging

Goal: Ensure confidentiality, integrity, and availability of personal data through layered technical and organizational measures — demonstrable and continuously verified.

Encryption¶

At rest (envelope model)
- Per-tenant Data Encryption Keys (DEKs) encrypt records/segments; DEKs are wrapped with region-scoped KMS/HSM Key Encryption Keys (KEKs).
- Rotation: KEKs quarterly (or on demand), DEKs rolling rotation (e.g., monthly or N records/GB). Re-encrypt-on-read/write without downtime.
- Key isolation: Keys never leave the region; wrap/unwrap happens in KMS/HSM. Split duties between key custodians and ops.
In transit
- External: TLS 1.3+, HSTS, modern cipher suites, OCSP stapling.
- Service-to-service: mTLS with SPIFFE/SPIRE identities or mesh-issued certs; certs auto-rotated; SANs restricted.
- Client → Gateway → Services: downgrade/legacy ciphers blocked; TLS termination points audited.

Policy excerpt (encryption)

encryption:
  atRest:
    tenantDek: envelope
    kmsRegionScope: true
    dekRotation: { cadence: "P30D", triggerBytes: "256GiB" }
    kekRotation: { cadence: "P90D", emergencyRotate: true }
  inTransit:
    externalTls: "TLS1.3+"
    mtls: required
    hsts: enabled

Access controls¶

AuthZ stack: RBAC + ABAC with tenant, role, scope, edition, residency, and classification attributes enforced at ingestion, query, export.
JIT elevation & time bounds: Temporary grants require dual approval and expire automatically; recorded in meta-audit.
Service identities: Non-human service principals with least privileges; short-lived tokens; audience-bound.
Secrets: No inline secrets; all credentials in Key Vault/HSM; access via managed identities.

OPA/Rego (sketch)

package atp.authz

allow {
  input.token.tenant == input.request.tenant
  input.token.scopes[_] == "aud:query"
  input.token.abac.region == input.request.region
  input.token.abac.classification_clearance >= input.request.classification
}

Integrity (tamper-evidence)¶

Hash chains & Merkle segmentation per stream/partition; region-local anchors + optional external timestamping/notary.
Periodic verification: Scheduled jobs recompute roots; drift triggers IntegrityViolation with automatic quarantine.
Migration safety: On move/rebuild, re-anchor with provenance manifests; proofs remain verifiable historically.

Confidentiality (minimization & redaction)¶

Classification-first (platform/pii-redaction-classification.md): write/read redactors, credential drops, PHI masking.
Logging hygiene: Structured logs mark sensitive fields and apply redactors at source; high-cardinality values hashed.
Data discovery: CI scanners ensure no unclassified fields in schemas; runtime counters alert on unclassified ingress.

Operational safeguards¶

Hardening & patching: Baseline CIS images, automatic security updates, canary rollouts with rollback.
DDoS & rate limits: At gateway + per-tenant quotas; backpressure patterns documented.
Backup security: Encrypted backups (per-tenant keys), immutable retention, residency-aligned classes; periodic restore drills.
Monitoring: SIEM ingestion of security events (key ops, auth failures, guard violations, integrity checks).

Evidence (auditor-ready)¶

KMS key policies & rotation logs, KEK/DEK rotation attestations.
TLS/mTLS configuration reports, certificate inventories, rotation proofs.
Integrity verification reports (roots, proofs, failure cases + remediations).
AuthZ decision logs (OPA evaluations), redaction metrics, backup/restore drill reports.

Metrics & SLOs¶

crypto.dek.rotate.success.rate (target ≥ 99.9%), crypto.unwrap.latency.p95
authz.denied.count (by reason), guard.violation.count
integrity.verify.success.rate (target 100%), integrity.violation.mttd
tls.version.distribution (100% TLS1.3), cert.rotation.on_time.rate (100%)

Alignment & cross-references

platform/security-compliance.md §5–8 · hardening/tamper-evidence.md · platform/data-residency-retention.md §5 · platform/pii-redaction-classification.md

Goal: Detect, assess, and notify personal-data breaches in a way that minimizes harm to data subjects and proves compliance with GDPR timelines and content requirements.

Detection¶

Signals: Anomaly detection (unusual access patterns), integrity check failures, guard violations, privilege escalations, exfiltration indicators, and unauthorized access alerts from SIEM.
Sources: Meta-audit stream, OPA deny logs, KMS key-op logs, gateway WAF/DDoS events, integrity verification jobs.
First response: Auto-create Incident Ticket (P1–P4), assign commander, start clock and preservation of evidence.

Triage & Assessment¶

Scope determination: Affected tenants/regions, categories of data (including special categories/PHI), approximate # of records and # of data subjects.
Risk to rights & freedoms: Consider sensitivity, likelihood of misuse, exposure duration, mitigation already in place (e.g., strong encryption with region-held keys).
Decision outcomes
- Not a personal-data breach → close with rationale; record in register.
- Breach with low risk → record only (Art. 33(5)); no notification required.
- Breach with risk → notify Supervisory Authority within 72 hours (Art. 33); if later, include reason for delay.
- Breach with likely high risk → also notify affected data subjects without undue delay (Art. 34).

Risk decision matrix (summary)

Encryption state	Data type	Misuse likely?	Risk level	Notify DPA (≤72h)	Notify subjects
Strong, keys in-region	Non-sensitive	Unlikely	Low	No	No
Strong, keys in-region	Sensitive/PHI	Possible	Risk	Yes	Case-by-case
Weak/none	Any	Possible/likely	High	Yes	Yes

Notification workflow¶

Containment & preservation: Revoke tokens/keys, isolate services/tenants, snapshot logs and systems for forensics.
Assessment pack: Facts of incident, categories/volume, root cause hypothesis, mitigations, contact for DPO.
DPA notification (≤72h): Submit via lead Supervisory Authority channel (one-stop-shop where applicable). If >72h, include justification.
Data subject notification (when likely high risk): Clear language, nature of breach, likely consequences, measures taken, and recommended steps (e.g., credential reset).
Follow-ups: Rolling updates as facts evolve; final incident report with corrective/preventive actions (CAPA).

DPA notification content (minimum)

Nature of breach, categories and approximate number of data subjects and records affected
DPO/contact details
Likely consequences of the breach
Measures taken or proposed to address the breach and mitigate adverse effects

Subject notification essentials

Plain-language summary of incident and potential impacts
What ATP and tenant have done; what the individual should do (e.g., change password)
Contact for more information (DPO/support)

Evidence & records¶

Article 33(5) breach register: Facts, effects, remediation, timing of all decisions and notifications.
Artifacts: Incident timeline, SIEM evidence, integrity proof diffs, key-op logs, copies of authority/subject notices, CAPA plan, post-incident ADRs.
Retention: Breach records retained per legal requirement; linked to meta-audit entries and residency region.

Metrics & SLAs¶

incident.time_to_detect (MTTD), incident.time_to_contain (MTTC)
gdpr.dpa.notified.within_72h.rate (target: 100%)
gdpr.subject.notified.on_time.rate (target: 100% when applicable)
Recurrence rate of similar root causes (target: ↓ over time)

Templates (excerpts)¶

Breach record (JSON)

{
  "id": "BR-2025-00123",
  "tenantIds": ["t-123","t-789"],
  "regions": ["EU"],
  "detectedAt": "2025-10-30T08:12:00Z",
  "firstContainmentAt": "2025-10-30T09:01:00Z",
  "dataCategories": ["Personal","Sensitive"],
  "subjectsApprox": 1240,
  "recordsApprox": 18650,
  "encryptionState": "DEK+KMS (region-held keys)",
  "riskLevel": "High",
  "dpaNotifiedAt": "2025-10-30T11:05:00Z",
  "subjectsNotifiedAt": "2025-10-30T15:20:00Z",
  "dpoContact": "dpo@connectsoft.ai",
  "measures": ["key-rotate","token-revoke","policy-fix"],
  "rootCause": "pending",
  "capas": ["ADR-SEC-042","PATCH-IMG-2025-10"],
  "links": ["meta-audit://events/...", "siem://cases/..."]
}

Subject notice (outline)

We are writing to inform you of a security incident that may have involved your personal data. On [date], we detected [nature]. We immediately contained the incident and implemented additional safeguards. Based on our investigation, the information potentially affected includes [categories]. We recommend [actions]. For questions, contact [DPO/contact].

Alignment & cross-references

platform/security-compliance.md §11 (incident response) · platform/data-residency-retention.md · platform/pii-redaction-classification.md

HIPAA Compliance Overview¶

Goal: Ensure ATP can lawfully process and safeguard PHI/ePHI for U.S. healthcare use cases and provide auditable proof of compliance with HIPAA’s Privacy, Security, and Breach Notification Rules.

Scope & roles¶

Regulation scope — U.S. Protected Health Information (PHI) in any form, including electronic PHI (ePHI) contained within audit events.
ATP role — Typically a Business Associate (BA) to Covered Entities (or to other BAs) when ATP processes PHI on their behalf (audit/accountability purposes).
Subcontractors — Any ATP subprocessors that may handle PHI act as BA subcontractors; ATP maintains BAAs and verifies downstream safeguards.

Applicability & obligations¶

Business Associate Agreements (BAAs) — Executed with Covered Entity customers and relevant subprocessors; define permitted uses/disclosures, safeguards, incident reporting, and termination/return-or-destroy terms.
Minimum necessary — ATP enforces least-privilege access and classification/redaction to limit PHI exposure in audit streams.
Documentation & evidence — Policies, procedures, training, risk analyses, incident logs, and technical configurations retained and made available for review.

Key HIPAA rules (how ATP aligns)¶

Rule	What it requires	ATP alignment (high level)
Privacy Rule (45 CFR 160; 164 A–E)	Limits on uses/disclosures; individual rights; minimum necessary	Tenant-scoped purpose controls, DSAR/export workflows, redaction/tokenization, audit trails of disclosures
Security Rule (45 CFR 164 Subpart C)	Administrative, physical, technical safeguards for ePHI	Risk analysis, RBAC/ABAC, encryption (at rest/in transit), integrity proofs, SIEM, training, contingency planning
Breach Notification Rule (45 CFR 164 Subpart D)	Notify affected individuals, HHS, and sometimes media	Incident response runbooks, 60-day subject/HHS notification workflows, breach register, evidence packs

Processing boundaries¶

Permitted purposes — Security, compliance, and accountability auditing as defined in the BAA/DPA. No secondary use without explicit authorization.
Data minimization — Producers guided to avoid unnecessary PHI; ATP masks/tokenizes PHI by default where feasible (see platform/pii-redaction-classification.md).
Residency & encryption — Region-pinned storage with per-tenant keys and TLS 1.3+/mTLS; encryption supports HIPAA safe harbor scenarios (details in Security sections).

Evidence (auditor-ready)¶

Executed BAAs and subprocessor BAAs, risk analysis & risk management plans, security & privacy policies, workforce training records, change/patch logs, incident/breach registers, backup/DR drill reports.

Cross-references
platform/security-compliance.md · platform/pii-redaction-classification.md · platform/data-residency-retention.md · operations/backups-restore-ediscovery.md

HIPAA: Administrative Safeguards¶

Goal: Implement and prove organizational controls that protect ePHI throughout ATP’s operations — from risk analysis and workforce practices to incident response and contingency planning.

Security Management Process (45 CFR §164.308(a)(1))¶

Risk analysis
- Annual + change-driven assessment covering assets, data flows, threats, vulnerabilities, and existing controls.
- Standardized scoring (Likelihood × Impact) with risk register entries (owner, target date, treatment).
- Outputs feed ADRs and the security roadmap.
Risk management
- Treatment options: mitigate, transfer, accept (with sign-off), or avoid.
- Track remediation via control backlog; verify via post-fix tests (SAST/DAST, tabletop).
Sanction policy
- Progressive discipline for policy violations (training → warning → suspension → termination).
- Evidence: signed policy acknowledgments, incident/sanction logs, HR attestations.
Information system activity review
- Weekly SIEM review of access logs, auth failures, guard violations, key operations.
- Monthly sample of PHI-related streams for appropriateness of access (“minimum necessary” check).
- Findings captured as tickets with CAPA (Corrective/Preventive Actions).

Artifacts: Risk Assessment Report, Risk Register, Sanction Policy, Monthly Activity Review reports.

Assigned Security Responsibility (45 CFR §164.308(a)(2))¶

Security Officer (SO) — accountable for HIPAA security program execution (risk mgmt, training, audits, incident coordination).
Deputy SO — continuity during absence; maintains playbooks and metrics.
DPO/Privacy Officer — coordinates privacy, DSARs, BAAs, breach communications.
RACI (excerpt)

Control Area	R	A	C	I
Risk analysis & register	SecOps Lead	Security Officer	DPO, SRE	Exec
Workforce training	People Ops	Security Officer	DPO	All
Access reviews (quarterly)	Identity Eng	Security Officer	DPO, HR	Exec
Incident response	SecOps Lead	Security Officer	DPO, Legal	All

Workforce Security (45 CFR §164.308(a)(3))¶

Joiner-Mover-Leaver (JML)
- Joiner: role-based access profiles; Just-In-Time (JIT) approvals; MFA enforced.
- Mover: access modified via change request; least-privilege re-evaluation.
- Leaver: access revoked ≤ 1 hour from termination; keys/tokens rotated; device return checklist.
Authorization & supervision
- Managers attest to need-to-know; quarterly recertification of privileged accounts.
- Background checks per role and jurisdiction; exceptions documented.

Artifacts: JML tickets, access attestations, revocation logs, background check confirmations.

Information Access Management (45 CFR §164.308(a)(4))¶

Minimum necessary — ABAC enforces PHI access by tenant/stream/classification/residency.
Access establishment/modification — via identity workflows; dual-control for elevated scopes; time-boxed grants auto-expire.
Segregation of duties — Ops cannot view PHI content; split between platform ops (infra) and tenant data custodians.

Artifacts: Access control matrix, OPA policy bundles, OPA decision logs, role definitions.

Security Awareness and Training (45 CFR §164.308(a)(5))¶

Cadence: onboarding (≤ 30 days) + annual refresher + targeted modules (PHI handling, redaction, incident reporting).
Exercises: quarterly phishing simulations; breach tabletop twice a year.
Tracking: LMS records, quiz scores, remediation for non-completion.

KPIs: Training completion 100%, phishing fail rate ↓ quarter-over-quarter.

Security Incident Procedures (45 CFR §164.308(a)(6))¶

Detect → Triage → Contain → Notify → Recover (see security-compliance.md §11).
Classification: P1–P4 with HIPAA breach overlay (subject/HHS notification within 60 days if applicable).
Forensics: log preservation, chain-of-custody, timeline reconstruction, CAPA with owner and due date.

Artifacts: Incident tickets, breach register, notifications, post-incident reports, CAPA tracker.

Contingency Plan (45 CFR §164.308(a)(7))¶

Data backup plan — encrypted, residency-aligned backups; restore tests quarterly with attestation.
Disaster recovery plan — documented RPO/RTO per tier; regional failover honoring residency; run tabletops and live drills.
Emergency mode operations — minimal services to maintain security logging and access control; break-glass with dual-approval; enhanced auditing.
Applications/data criticality analysis — tiering of services and PHI impact mapping.

Artifacts: Backup/DR runbooks, drill reports, RPO/RTO dashboard, emergency mode checklist.
Refs: operations/backups-restore-ediscovery.md, data-residency-retention.md.

Business Associate Contracts (45 CFR §164.308(b)(1))¶

BAAs with subprocessors — permitted uses/disclosures, safeguards, breach notification flow-down, termination & data return/destruction.
Intake & monitoring — security questionnaires, SOC2/ISO reports, right-to-audit clauses, annual re-assessment.
Register — current list of subprocessors (scope, data types, regions) disclosed to customers.

Artifacts: Executed BAAs, vendor assessments, subprocessor register, annual review logs.

Metrics & SLAs (program health)¶

Risk remediation SLA: High ≤ 30 days, Medium ≤ 90 days.
Access recert completion: 100% per quarter.
Offboarding revoke time: p95 ≤ 60 minutes.
Backup restore success: ≥ 99.5%; mean restore time within RTO.
Incident MTTC/MTTR: tracked; goal trending downward.

Dashboards: HIPAA admin safeguards board with live metrics and evidence links.

Cross-references

platform/security-compliance.md §11 · platform/pii-redaction-classification.md · platform/data-residency-retention.md · operations/backups-restore-ediscovery.md

HIPAA: Physical Safeguards¶

Goal: Protect ePHI by relying on proven cloud datacenter controls, enforcing hardened endpoint baselines for personnel, and ensuring secure handling/disposal of any media that could store ePHI.

Facility Access Controls (45 CFR §164.310(a))¶

Shared responsibility
- ATP does not operate physical datacenters; relies on cloud provider facilities with multilayer physical security (badging, biometrics, mantraps, CCTV, visitor logs).
- Evidence obtained via provider SOC 2/ISO 27001 reports and contractual right-to-audit clauses.
Logical isolation
- Network segmentation, private endpoints, and residency pinning reduce physical-access blast radius even within provider facilities.
Business premises
- If ATP staff work in corporate offices, physical access is controlled by badges + logs; visitors escorted and logged; clean-desk policy for any PHI-related work.

Artifacts: Cloud provider SOC/ISO reports, subprocessor register, office access logs (if applicable), visitor logs, facility security policy.

Workstation Use/Security (45 CFR §164.310(b)-©)¶

Standard build (MDM-enforced)
- Full-disk encryption (BitLocker/FileVault), MFA, screen auto-lock ≤ 5 minutes, firewall enabled, USB storage blocked by default.
- EDR (endpoint detection & response) + anti-malware; OS/browser auto-updates; least-privilege (no local admin for standard users).
- VPN/Zero Trust access; device posture checks before granting access to production systems.
- Data handling: PHI views in admin consoles only; copy/download disabled unless explicitly authorized and logged.
Acceptable use
- Prohibit saving ePHI to local desktop, personal cloud, or removable media.
- Remote wipe for lost/stolen devices; incident ticket auto-created after user self-report or MDM alert.

Artifacts: MDM compliance dashboard, encryption attestations, EDR coverage report, workstation baseline policy, AUP acknowledgments, remote-wipe logs.

Device and Media Controls (45 CFR §164.310(d))¶

Media lifecycle
- Inventory of any media that could store ePHI (service laptops, encrypted portable drives used for disaster scenarios).
- Creation: Only encrypted media (AES-256) with keys in KMS/HSM; access least-privilege.
- Transfer: Courier or tamper-evident shipping not used for routine ops; prefer in-region cloud transfers.
- Reuse/Disposal: Follow NIST 800-88 guidelines (cryptographic erase or physical destruction by certified vendor). Cloud snapshots/volumes are sanitized per provider commitments; ATP records deletion requests and confirmations.
Backups
- Backups are encrypted, residency-aligned, and immutable (WORM policies) with restore drills (see operations/backups-restore-ediscovery.md).
- Export-before-delete artifacts never land on unmanaged media; delivery only to tenant-controlled, region-pinned storage.
Media accountability
- Media ID, owner, purpose, custody chain, and final disposition recorded; no personal devices permitted.

Artifacts: Media inventory & custody logs, destruction certificates, backup encryption configs, restore drill reports.

Metrics & SLAs¶

workstations.encryption.coverage = 100%
workstations.autolock.enabled.rate = 100%, autolock.timeout.p95 ≤ 5m
edr.coverage = 100%; mdm.noncompliant.devices = 0
removable.media.blocked.events (alert on >0)
media.disposal.attestations.count (quarterly ≥ 1 if disposals occurred)
backup.encryption.coverage = 100%; restore.success.rate ≥ 99.5%

Quick policy excerpt (YAML)¶

endpoints:
  encryption: required
  screenLock: { enabled: true, timeoutMinutes: 5 }
  edr: required
  removableMedia: blockedByDefault
  adminRights: justInTime
media:
  tracking: inventoryRequired
  encryption: required
  disposal: NIST-800-88
  exportToLocal: prohibited

Cross-references

platform/security-compliance.md · operations/backups-restore-ediscovery.md · platform/data-residency-retention.md · platform/pii-redaction-classification.md

HIPAA: Technical Safeguards¶

Goal: Enforce technical controls that protect ePHI confidentiality, integrity, and availability across identities, services, data flows, and networks — with auditable evidence of effectiveness.

Access Control (45 CFR §164.312(a))¶

Unique user identification — All users and service principals have globally unique IDs; short-lived tokens bound to audience, tenant, scopes.
Authorization — RBAC + ABAC at ingestion/query/export; conditions include tenantId, region, classificationClearance, edition, and time-bound grants.
Emergency access (break-glass) — Dual-approval, time-boxed elevation with expanded logging; post-incident review and automatic revocation.
Automatic logoff — Idle session TTLs (UI/CLI/API) with token expiry/refresh floor; admin consoles force re-auth for privileged actions.
Encryption/decryption — Decrypt only in memory within secure service boundary; per-tenant DEKs via KMS/HSM (see encryption policy).

OPA/Rego (sketch)

package atp.access

default allow = false

allow {
  input.auth.user_id != ""
  input.auth.tenant == input.req.tenant
  some s
  input.auth.scopes[s] == "aud:query"
  input.auth.abac.clearance >= input.req.data_class
  time.now_ns() < input.auth.expires_ns
}

Audit Controls (45 CFR §164.312(b))¶

Immutable audit — Every PHI read/write/export emits a meta-audit event (actor, subject, purpose, scope, decision, hashes).
Tamper resistance — Meta-audit stream is append-only with segment hashing and periodic root anchoring.
Review cadence — Daily anomaly triage; weekly PHI-access sampling; quarterly auditor packs.

Audit event (example)

{
  "event": "PHI_ACCESS",
  "tenantId": "t-123",
  "actor": {"type":"user","id":"u-42","roles":["auditor"]},
  "scope": {"stream":"ehr.audit","region":"US"},
  "decision": "allow",
  "dataClasses": ["PHI","Personal"],
  "redactionPlan": "policy-atp-v1#12",
  "traceId": "9f5c...",
  "hash": "b0b1...",
  "ts": "2025-10-30T08:41:22Z"
}

Integrity (45 CFR §164.312©(1))¶

Hash chains & Merkle segments — Each stream partition forms verifiable chains; roots anchored per region with optional external timestamping.
Verification jobs — Scheduled recomputation; deviations raise IntegrityViolation and isolate affected segments (read-only until reconciled).
Migration safety — Re-anchoring with provenance manifests during reindexing or region moves (see hardening/tamper-evidence.md).

Person or Entity Authentication (45 CFR §164.312(d))¶

Users — MFA required for all privileged roles; FIDO2/WebAuthn preferred; device posture checks for admin consoles.
Services — mTLS (SPIFFE/SPIRE or mesh certs), short-lived service credentials, audience-restricted JWTs; no shared secrets.
Key custody — Secrets in HSM/Key Vault; rotation and attestation logged.

Transmission Security (45 CFR §164.312(e)(1))¶

TLS 1.3+ end-to-end; HSTS; modern cipher suites; perfect forward secrecy; OCSP stapling; TLS downgrade blocked.
Intra-mesh — mTLS with strict SAN verification; certificate auto-rotation.
Integrity controls — Export bundles include checksums and detached signatures; gateway applies request/response size and rate guards.

Policy excerpt (YAML)

technicalSafeguards:
  access:
    rbac: required
    abac: [tenantId, region, classificationClearance, edition]
    autoLogoff: { uiMinutes: 15, cliMinutes: 15, apiTokenTtlMinutes: 30 }
    breakGlass: { approvals: [SecurityOfficer, DPO], maxDurationMinutes: 60 }
  authentication:
    userMfa: required
    serviceMtls: required
    tokenLifetime: "PT30M"
  transmission:
    tlsMinVersion: "1.3"
    hsts: enabled
    exportSigning: required

Artifacts (auditor-ready)¶

Access control matrix, OPA/Rego bundles, authorization decision logs.
TLS/mTLS configs, certificate inventories, rotation proofs.
Meta-audit samples, integrity verification reports, export manifests + signatures.

Metrics & SLAs¶

authn.mfa.coverage = 100% (privileged)
authz.denied.count (by reason), breakglass.usage.count (≤ predefined threshold)
integrity.verify.success.rate = 100%, integrity.violation.mttd
tls.version.distribution (100% TLS1.3), cert.rotation.on_time.rate = 100%

Cross-references

platform/security-compliance.md §5–8 · hardening/tamper-evidence.md · platform/data-residency-retention.md §5

SOC 2 Compliance Overview¶

Goal: Achieve and maintain SOC 2 Type II attestation that covers both the design and operating effectiveness of ATP’s controls over an observation period, aligned to the AICPA Trust Services Criteria (TSC).

Framework & scope¶

Framework: AICPA TSC with Security (common criteria) always in scope; ATP targets Availability, Processing Integrity, and Confidentiality. Privacy may be added based on customer demand.
Service context: ATP is a SaaS that processes customer data on a multi-tenant platform with strong tenancy isolation and policy-as-code enforcement.
Attestation type: Type II (6–12 month observation period) following an initial readiness/Type I checkpoint if needed.

System description & boundaries (high level)¶

In scope: API Gateway, Ingestion, Policy/Guard, Storage/Integrity, Query, Export, Observability/SIEM, KMS/HSM integrations, CI/CD, and Ops runbooks.
Out of scope: Tenant applications and data producers/consumers outside ATP’s boundary; underlying cloud IaaS physical controls (covered via provider SOC reports).
CUECs (Complementary User Entity Controls): Tenant responsibilities (e.g., credential hygiene, producer-side data minimization, secure API usage) documented and communicated.

Roles & responsibilities¶

Control owners: Identity/Platform, SRE/Operations, Security Officer, DPO/Privacy, and ATP service teams.
Evidence stewards: Security & Compliance team curates artifacts (policies, logs, tests, ADRs, drill reports) and manages the evidence portal for auditors.

Attestation cadence & milestones¶

Readiness: gap assessment, policy hardening, evidence pipelines, control mapping.
Observation (Type II): 6–12 months of operating evidence with periodic sampling.
Report issuance: external auditor delivers SOC 2 Type II report; customer distribution via NDA.

Evidence strategy (continuous)¶

Policy-as-code + automation: OPA/Rego checks in CI/CD; drift detection in runtime configs.
Telemetry-backed proof: SIEM dashboards, integrity verification reports, access recert logs, backup/DR drill attestations.
Subservice org reliance: Cloud provider SOC 2 Type II and ISO 27001 reports (carve-out method) with annual review and gap analysis.

Quick policy excerpt (YAML)

soc2:
  scope:
    criteria: [Security, Availability, ProcessingIntegrity, Confidentiality]
    privacyOptional: true
  attestation:
    type: TypeII
    observationMonths: 9
  evidence:
    continuousControls: true
    dashboards: ["security-posture", "integrity-verification", "backup-restore"]
    cuecsPublished: true
  subserviceOrgs:
    method: carveOut
    reports: ["Azure-SOC2-TypeII", "Azure-ISO27001"]

Artifacts (auditor-ready) System description, control matrix, policies & procedures, CI/CD security gates, access reviews, KMS/key-rotation logs, integrity verification packs, DR drill reports, vulnerability/patch records, incident response evidence.

Cross-references

platform/security-compliance.md · platform/data-residency-retention.md · platform/pii-redaction-classification.md · operations/observability.md · operations/backups-restore-ediscovery.md

SOC 2: Trust Services Criteria Mapping¶

Goal: Map ATP controls and evidence to the AICPA Trust Services Criteria to support Type II attestation, with owners and test cadence.

Common Criteria (CC) — Security¶

CC1.0 Control Environment

Controls: Published security policy set; org chart with role charters; code of conduct with annual attestation; ADRs for security-impacting changes.
Evidence: Policy repository, signed acknowledgments, role/RACI matrix, ADR index.
Tests: Document inspection (quarterly), sample staff attestations (monthly).
Owner: Security Officer, People Ops.

CC2.0 Communication & Information

Controls: Security awareness training program; incident comms playbook; runbook library; stakeholder broadcasts for control changes.
Evidence: LMS completion logs, incident comms templates, runbook repo.
Tests: Training completion review (quarterly), incident comms tabletop (biannual).
Owner: Security Officer, Comms Lead.

CC3.0 Risk Assessment

Controls: Threat modeling (STRIDE) per service; risk register with likelihood/impact; periodic reassessment gates.
Evidence: Threat model diagrams, risk register entries with owners/ETAs.
Tests: Risk review boards (quarterly), spot-check mitigations.
Owner: SecArch, Security Officer.

CC4.0 Monitoring Activities

Controls: SIEM detections, guard violation alerts, integrity verification jobs, internal audit sampling.
Evidence: SIEM dashboards, alert runbooks, integrity job reports, audit findings.
Tests: Detection efficacy review (monthly), control sampling (quarterly).
Owner: SRE/SecOps, Internal Audit.

CC5.0 Control Activities

Controls: Logical access approvals (JIT), key management, change windows, segregation of duties.
Evidence: Access tickets, KMS logs, change records, SoD matrix.
Tests: Access recertification (quarterly), key rotation verification (quarterly).
Owner: Identity Eng, Platform.

CC6.0 Logical & Physical Access

Controls: RBAC+ABAC tenancy guards; MFA; break-glass dual-approval; reliance on cloud SOC reports for physical.
Evidence: OPA/Rego bundles and decision logs, MFA coverage report, break-glass register, provider SOC2/ISO reports.
Tests: ABAC policy tests (CI + monthly), MFA coverage check (monthly).
Owner: Identity Eng, Security Officer.

CC7.0 System Operations

Controls: Capacity/SLO dashboards; incident response (P1–P4); backup/DR with RPO/RTO; post-incident CAPA.
Evidence: SLO reports, incident tickets, restore drill attestations, DR playbooks.
Tests: DR drills (quarterly), incident PIR reviews (per incident).
Owner: SRE/Operations.

CC8.0 Change Management

Controls: Git-based change control, CI/CD quality gates (SAST/DAST/SBOM), peer review, canary/rollback.
Evidence: PR reviews, pipeline artifacts, release notes, rollback records.
Tests: Change sampling (monthly), pipeline gate audit (quarterly).
Owner: Eng Leads, DevEx.

CC9.0 Risk Mitigation

Controls: Vulnerability management (scanner SLAs), patch cadence, external pentests, bug bounty intake.
Evidence: Vuln backlog with SLAs, patch logs, pentest reports, bounty tickets.
Tests: SLA adherence review (monthly), remediation verification (rolling).
Owner: SecOps, Eng Leads.

Additional Criteria — Availability (A)¶

A1.0 Availability Commitments

Controls: Multi-region architecture with residency-aware failover; SLAs; capacity modeling; HAs for gateways and storage.
Evidence: Architecture diagrams, SLA doc, failover configs.
Tests: Region failover exercise (quarterly), chaos tests for node loss (monthly).
Owner: SRE/Platform.

A2.0 Monitoring & Incident Response

Controls: Synthetic probes, golden-signal alerts, on-call rotations, RPO/RTO objectives by tier.
Evidence: Alert runbooks, on-call schedules, RTO/RPO dashboard.
Tests: Alert drill (monthly), paged response MTTA/MTTR review (monthly).
Owner: SRE.

Additional Criteria — Processing Integrity (PI)¶

PI1.0 Accuracy, Completeness, Timeliness

Controls: Append-only ingestion, idempotency keys, hash chains/Merkle roots, reconciliation jobs, DLQ with replay.
Evidence: Integrity verification reports, reconciliation logs, DLQ drain records.
Tests: Weekly integrity recomputation; replay test in staging (biweekly).
Owner: ATP Service Team, SRE.

Additional Criteria — Confidentiality (C)¶

C1.0 Confidentiality Protection

Controls: Classification & redaction (platform/pii-redaction-classification.md), per-tenant encryption keys, export signing, least-privilege.
Evidence: Policy bundles, KMS key maps, export manifests/signatures.
Tests: Redaction unit/integration tests (CI), key rotation verification (quarterly).
Owner: Security Officer, Platform.

Additional Criteria — Privacy (P) (optional scope)¶

P1.0–P8.0 Notice / Choice / Collection / Use–Retention–Disposal / Access / Disclosure / Quality / Monitoring

Controls: Published privacy notices; DSAR workflows; retention & deletion (holds honored); disclosure tracking; data quality checks; privacy monitoring.
Evidence: DSAR logs, retention/purge logs, hold registers, privacy policy versions.
Tests: DSAR SLA audits (monthly), purge dry-run simulations (quarterly).
Owner: DPO/Privacy, Security & Compliance.

Control summary table (sample)¶

Criterion	Key Controls	Primary Evidence	Test Cadence	Owner
CC6	RBAC/ABAC + MFA + break-glass	OPA logs, MFA report, break-glass register	Monthly	Identity
A1	Residency-aware HA & failover	DR playbooks, failover configs	Quarterly	SRE
PI1	Hash chains, idempotency, DLQ replay	Integrity reports, replay logs	Weekly	ATP Team
C1	Redaction + per-tenant KMS	Policy bundles, KMS logs	Quarterly	Security/Platform

Cross-references

platform/security-compliance.md · platform/data-residency-retention.md · platform/pii-redaction-classification.md · operations/observability.md · operations/backups-restore-ediscovery.md

Evidence Artifacts & Attestation Process¶

Goal: Maintain a living, auditor-ready body of proof that ATP’s privacy and security controls are designed, implemented, and operating effectively across GDPR, HIPAA, and SOC 2.

Evidence Collection¶

Policies & Procedures
- Security policy set, incident response, data classification/redaction, retention & deletion, access reviews, vendor management.
- Versioned with approvals (owner, approver, effective date); diffs linked to ADRs.
Technical Artifacts
- Audit logs (immutable/meta-audit), integrity proofs (Merkle roots, verification reports), encryption configs (per-tenant KMS bindings), access control matrices (RBAC/ABAC), OPA decision logs.
- Residency/replication configs; backup/restore attestations.
ADRs
- Security- and privacy-impacting decisions with rationale, alternatives, and links to tests/runbooks.
Test Results
- Penetration tests (internal/external), compliance test suites, redaction/classification unit+integration tests, chaos experiments (DR, credential rotation, policy skew).
Operational Logs
- Change/patch logs, incident & breach registers, DSAR workflow logs, access recertifications, workforce training records, subprocessor reviews.

Evidence store (sketch)

/evidence
  /policies/2025-01/security-policy-v3.pdf
  /adrs/ADR-012-privacy-by-default.md
  /tests/penetration/2025Q1-external-pentest.pdf
  /integrity/2025-10/segment-roots.ndjson
  /kms/tenant-key-bindings.csv
  /incidents/breach-register.csv
  /training/2025/hipaa-training-completions.csv
  /dsar/requests/REQ-2025-0047/manifest.json
````

**Evidence manifest (example)**

```json
{
  "id": "EV-2025-10-ATP",
  "generatedAt": "2025-10-30T08:55:00Z",
  "scope": ["GDPR", "HIPAA", "SOC2"],
  "controls": ["CC6", "Art32", "164.312"],
  "artifacts": [
    {"path":"integrity/2025-10/segment-roots.ndjson","sha256":"..."},
    {"path":"kms/tenant-key-bindings.csv","sha256":"..."},
    {"path":"policies/2025-01/security-policy-v3.pdf","sha256":"..."}
  ],
  "signature": {"alg":"ed25519","value":"<detached-sig>"}
}

Auditor Workflows¶

Access Model
- Read-only, time-bound credentials to evidence portals; least-privilege project spaces.
- Sensitive exports are watermarked; downloads logged with chain-of-custody IDs.
Sampling & Requests
- Predefined sampling plans: monthly access reviews, quarterly DR drills, weekly integrity verifications.
- Templated PBC (Provided By Client) request tracker with owners and due dates; SLA reminders.
Sessions & Walkthroughs
- Scheduled control walkthroughs (authn/z, residency, DSAR), demo in staging with scrubbed data.
- Escalation path for gaps (Security Officer → DPO → Exec sponsor).

Chain-of-custody (mini-schema)

cocId: COC-2025-1021-07
requestId: PBC-CC6-AccessReview
grantedTo: auditor@firm.com
grantedAt: 2025-10-21T09:00:00Z
expiresAt: 2025-11-04T09:00:00Z
artifacts: [ "access-reviews/2025Q3/report.pdf", "opa/decisions/sample.ndjson" ]
watermark: "CONFIDENTIAL • SOC2 USE ONLY • COC-2025-1021-07"

Continuous Compliance¶

Dashboards
- Real-time posture per framework: encryption coverage, MFA coverage, retention compliance, integrity verification rate, DSAR SLA.
Automated Checks
- OPA/Rego and CI/CD gates for policy conformance; drift detection for KMS bindings, network boundaries, and ABAC policies.
- Daily retention enforcement verification and export signing checks.
Quarterly Reviews
- Control effectiveness review, risk reassessment, evidence refresh cycle, and update of the auditor-facing system description.

KPIs & SLAs

evidence.freshness.avg_days ≤ 30 (policy/test artifacts)
mfa.coverage.privileged = 100% · encryption.at_rest.coverage = 100%
integrity.verify.success.rate = 100% · dr.drill.execution.rate ≥ 1/quarter
dsar.on_time.rate ≥ 95% (GDPR 30-day SLA)
pbc.request.turnaround.p50 ≤ 3 days

Cross-references

platform/security-compliance.md · platform/data-residency-retention.md · platform/pii-redaction-classification.md · operations/observability.md · operations/backups-restore-ediscovery.md

Article	Requirement	ATP Control	Evidence
Art. 5	Principles (lawfulness, minimization, accuracy, storage limitation, integrity, accountability)	Privacy-by-design, retention policies, immutability	ROPA, policy docs, audit logs
Art. 15	Right of access	DSAR export workflow	Export logs, manifests
Art. 16	Right to rectification	Append-only corrections	Correction audit trail
Art. 17	Right to erasure	Post-retention deletion (with holds)	Deletion logs, hold records
Art. 20	Right to data portability	Structured export formats	Export formats, manifests
Art. 25	Data protection by design	Privacy-by-design principles	Architecture docs, ADRs
Art. 30	Records of processing	ROPA for ATP operations	ROPA document
Art. 32	Security of processing	Encryption, access controls, integrity	Security configs, test results
Art. 33-34	Breach notification	Incident response procedures	Incident logs, notifications

Appendix B — HIPAA Safeguards Checklist¶

Administrative: Security officer assigned, workforce training, incident procedures, contingency plan, BAA in place.
Physical: Cloud datacenter security verified, workstation security policies, encrypted media disposal.
Technical: Unique user IDs, MFA, audit controls (immutable logs), integrity (hash chains), transmission security (TLS 1.3+).

Appendix C — SOC 2 Control Matrix (Sample)¶

Control ID	TSC Category	Description	Owner	Test Frequency
CC6.1	Logical Access	RBAC + ABAC enforcement	Identity	Quarterly
CC6.6	Logical Access	MFA for admin operations	Identity	Monthly
CC7.2	System Operations	Immutable audit logs	ATP	Continuous
PI1.2	Processing Integrity	Hash chain verification	ATP	Weekly
C1.1	Confidentiality	PII redaction on write/read	ATP	Quarterly
A1.3	Availability	Regional failover tested	SRE	Quarterly

Appendix D — Cross-Reference Map¶

Privacy Topic	Primary Implementation Doc	Notes
Tenant isolation & ABAC	`platform/multitenancy-tenancy.md`	Data subject scoping
Encryption & key management	`data-residency-retention.md` §5, `hardening/key-rotation.md`	At-rest, in-transit
PII classification & redaction	`platform/pii-redaction-classification.md`	Minimization, anonymization
Residency enforcement	`data-residency-retention.md` §2-4, §21	GDPR territorial scope
Retention & deletion	`data-residency-retention.md` §6-8	Storage limitation
Integrity & tamper-evidence	`hardening/tamper-evidence.md`	HIPAA integrity, SOC2 PI
Incident response	`security-compliance.md` §11	Breach notification
DSAR/export workflows	`guides/export-and-ediscovery.md`	Subject access rights

Goal: Maintain an Article 30–compliant register of processing activities that covers ATP’s roles as processor (for tenant audit data) and controller (for meta-audit, telemetry, and administrative operations).

Scope — Activities where ATP processes personal data:
- Processor role: Tenant audit ingestion, storage, query, export (per tenant contract).
- Controller role: Platform meta-audit (who did what in ATP), service telemetry limited to ops data, billing/administration.
Contents — Controller/processor details, processing purposes, data categories & subjects, recipients/subprocessors, cross-border transfers, retention periods, and security measures.
Updates — Quarterly review or on change (new subprocessor, new purpose/data category, residency change, retention policy change, DPIA result).
Availability — Exportable to supervisory authorities on request within the defined SLA (e.g., 7 business days), with chain-of-custody and watermarking.
Templates include — Tenant processing, meta-audit processing, administrative operations.

ROPA register (outline)

activityId: ROPA-ATP-0001
role: Processor            # or Controller
controller:
  name: <Tenant Legal Name>
  contactEmail: privacy@tenant.example
processor:
  name: ConnectSoft (ATP)
  contactEmail: dpo@connectsoft.ai
purposes:
  - Accountability/audit trail for tenant systems
dataSubjects:
  - Tenant end users
  - Tenant workforce users
dataCategories:
  - Personal (email, IP), Sensitive (address/phone), PHI (tenant-dependent)
recipients:
  - Subprocessors: [Azure (IaaS/PaaS), Monitoring/SIEM]
transfers:
  mechanism: "No cross-border by default; SCCs if applicable"
  regions: ["EU"]          # see data-residency-retention.md
retention:
  default: P7Y
  legalHold: supported
securityMeasures:
  - Encryption at rest (per-tenant keys), TLS 1.3+
  - ABAC/RBAC, least privilege, break-glass
  - Immutability, hash chains, integrity verification
lawfulBasis:
  - legitimateInterest
  - legalObligation (where applicable)
dpaReference: DPA-<tenant>-v3
subprocessorReports:
  - Azure-SOC2-TypeII-2025
dpo:
  name: ConnectSoft DPO
  email: dpo@connectsoft.ai
owner: Security & Compliance
lastReviewedUtc: 2025-10-30T08:58:00Z

Controller-side entry (meta-audit example)

activityId: ROPA-ATP-CTRL-001
role: Controller
purposes: ["Security monitoring", "Incident response", "Accountability for ATP ops"]
dataSubjects: ["Tenant admins using ATP", "ConnectSoft staff (ops)"]
dataCategories: ["Internal", "Personal (IDs, IP)", "Access metadata"]
retention: { default: P1Y, legalHold: supported }

Change control & evidence

Triggers: New subprocessor/region, policy version change (classification/retention), new data class, new export destination, DPIA outcome change.
Workflow: PR to ROPA repo → DPO approval → evidence bundle update → auditor dashboard refresh.
Artifacts: Versioned ROPA YAML/CSV, approval records, subprocessor SOC reports, DPIA references.

Storage & export

Registry stored in /compliance/ropa/ (Git, versioned).
Exports: CSV/PDF with signed manifest (hash, timestamp, signer), watermarked “Regulatory Use”.

Cross-references

platform/data-residency-retention.md · platform/pii-redaction-classification.md · platform/security-compliance.md · guides/export-and-ediscovery.md · privacy-gdpr-hipaa-soc2.md (this doc)

When required (triggers)

High risk to rights/freedoms: large-scale processing, systematic monitoring, new Sensitive/PHI categories, novel identifiers or linkage, automated decisioning/profiling.
New cross-border transfers or change of residency posture (e.g., adding replication outside EEA).
Introduction of new processors/sub-processors or significant architectural changes (new ingestion sources, new export surfaces).

ATP DPIA scope

Platform-wide audit processing that may include tenant PII/PHI across ingestion → storage → query → export.
Boundaries defined by tenant residency and tenancy isolation models; excludes tenant apps (captured as CUECs in SOC 2).

Process (standard workflow)

Initiate — DPIA request opened (change/epic links, purpose, proposed design, data classes involved).
Describe processing — Data flow diagram, categories of data/subjects, volumes, retention, transfers, recipients.
Lawful basis & necessity/proportionality — Justify audit purpose; confirm minimization, default redaction, and least-privilege access.
Risk assessment — Identify threats to confidentiality/integrity/availability and to data-subject rights; score likelihood × impact using the ATP risk matrix.
Mitigations — Map controls (classification/redaction, encryption, ABAC, residency, legal hold) and expected risk reduction.
Residual risk decision — Acceptable? If high residual risk remains, engage supervisory authority consultation.
DPO review & sign-off — DPO provides written advice; product/security owners record decision and actions.
Record & monitor — Store DPIA, link to ADRs/runbooks; define follow-ups (tests, evidence collection, control owners).
Re-evaluate — On material change or annually (whichever first).

Artifacts & evidence

DPIA form (template in Appendix E), data-flow diagrams, policy references, risk matrix, DPO advice, decision log, implementation ADRs, verification tests (pre-/post-deploy).

Roles & responsibilities

Requester/Owner: initiates, provides design/data details, implements mitigations.
Security/Privacy engineering: advises on controls, validates technical mitigations.
DPO: assesses compliance, documents advice, escalates when residual risk is high.
SRE/Operations: confirms residency, DR, monitoring, and evidence capture plans.

Tooling & automation

Policy-as-code gates (OPA/Rego) in CI to block deployments lacking a linked DPIA for high-risk changes.
Checklist linters for data classes/residency changes; evidence hooks to store DPIA outputs in the compliance repository.
Risk matrix codified with thresholds that trigger DPO review or SA consultation.

Typical timelines & SLAs

Screening: ≤ 3 business days.
Full DPIA: ≤ 20 business days (complex cases may extend with DPO notice).
Supervisory authority consultation: per regulator guidance once high residual risk is confirmed.

Update conditions

New data categories/classes; new jurisdictions or transfer mechanisms; control regressions; incidents with DPIA-covered processing.

Alignment

Cross-refs: security-compliance.md (controls/IR), data-residency-retention.md (residency/retention), pii-redaction-classification.md (minimization/redaction), deployment-views.md (boundaries/flows).

Goal: Establish an independent DPO function that advises on compliance, oversees ATP adherence to GDPR, and serves as the primary contact for supervisory authorities and data subjects.

Appointment & Independence¶

When required: Processing personal data at scale and as a core activity (ATP meets this bar).
Independence: Reports to the highest management; no conflict of interest with operational roles; protected from dismissal/penalties for performing DPO duties.
Resourcing: Adequate time, budget, and access to information and processing activities.

Responsibilities¶

Advisory: Counsel on GDPR obligations, privacy-by-design decisions, and DPIA necessity/scope (see DPIA section).
Monitoring: Track compliance with policies, training, audits, and remediation plans.
POC: Primary contact for supervisory authorities and for data subjects (DSAR coordination).
Governance: Maintain ROPA, oversee vendor/subprocessor privacy posture, and review policy updates.
Incident liaison: Guide breach assessment and notifications (with Security Officer).

Contact & Transparency¶

Public contact: DPO details published in privacy policy and tenant agreements.
Availability: Clear SLAs for regulator correspondence and DSAR queries.
Records: All DPO communications logged in the meta-audit stream with chain-of-custody.

DPO register (template)

dpo:
  name: "<Full Name>"
  email: "dpo@connectsoft.ai"
  phone: "+1-xxx-xxx-xxxx"
  reportsTo: "Chief Executive / Board"
  independenceStatement: "No conflicting operational responsibilities"
  lastAnnualReportUtc: "2025-09-30T00:00:00Z"
  coverage:
    processingActivities: ["Tenant audit data", "Meta-audit", "Administrative ops"]
    jurisdictions: ["EU/EEA", "US (HIPAA)"]
  sops:
    - "DPIA-review-v2"
    - "DSAR-handbook-v3"
    - "Breach-response-playbook-v4"

Governance Workflows & Escalation¶

Triggers: Privacy incidents/breaches, DSAR disputes, new high-risk processing proposals (new data classes/regions/processors).
Escalation path:
- P1 (critical): Potential reportable breach → DPO + Security Officer + Legal + Exec immediately.
- P2 (high): High-risk DPIA residual risk → DPO recommends supervisory authority consultation.
- P3 (standard): DSAR dispute or complex residency/redaction question → DPO adjudication within SLA.
Decisions & evidence: Written DPO advice recorded; links to ADRs, DPIAs, incident tickets.

SLAs (guidance)¶

DPIA screening: ≤ 3 business days; full advice ≤ 20 business days (complex cases may extend).
Regulator inquiries: Acknowledge ≤ 2 business days; substantive response per authority timeline.
DSAR oversight: Ensure responses within 30 days (GDPR), with extensions documented.

RACI (summary)¶

Activity	DPO	Security Officer	Product/Eng	Legal	SRE/Ops
DPIA review & advice	R/A	C	C	C	C
DSAR dispute resolution	R/A	C	C	C	C
Breach notification decision	A	R	C	C	C
Policy updates (privacy)	A	C	R	C	C
Regulator correspondence	R	C	C	A	C

Cross-references

privacy-gdpr-hipaa-soc2.md (DPIA, DSAR) · platform/security-compliance.md (incident response) · platform/data-residency-retention.md (residency/retention) · platform/pii-redaction-classification.md (minimization/redaction)

HIPAA: Minimum Necessary Standard¶

Goal: Ensure ATP uses, discloses, and grants access to PHI only to the extent necessary to accomplish a specific, legitimate purpose.

Principle¶

Limit use, disclosure, and access to the minimum necessary for the stated purpose.
Prefer summaries, metadata, or redacted views when full detail isn’t required.

Implementation (RBAC + ABAC + Purpose Binding)¶

Role- and attribute-based access: RBAC establishes coarse roles (e.g., auditor.phi, ops.readonly), while ABAC narrows access (tenant, site, specialty, care-team).
Purpose-bound tokens: JWT includes purpose (e.g., treatment, payment, operations) and clearance claims; requests must declare a use case.
Scoped queries: Server-side filters enforce need-to-know by patient, location, department, or investigation case.

OPA/Rego sketch (minimum necessary)

package atp.access

default allow = false

# Caller must have role AND purpose in allow list for PHI
viable_purpose[p] { p := input.token.purpose; p == "treatment"; } 
viable_purpose[p] { p := input.token.purpose; p == "operations"; input.request.aggregate == true }

# Field-level clearance: PHI fields require clearance >= "phi_masked" unless break-glass.
field_allowed(f) {
  f.sensitivity == "PHI"
  input.token.clearance == "phi_masked"
}

allow {
  input.token.roles[_] == "auditor.phi"
  viable_purpose[_]
  input.record.tenantId == input.token.tenantId
  # Care-team or assigned scope
  input.record.patientId == input.token.scopes.careTeam[_]
  # Only permitted fields
  forall f in input.request.fields { field_allowed(f) }
}

Query Filters & Views¶

Row-level predicates: WHERE tenant_id=@tenant AND patient_id IN (@care_team) AND site=@site
Column-level redaction: Return PHI as masked/tokenized unless clearance and purpose allow reveal.
Aggregations by default: For operations purpose, prefer counts/timeseries over raw PHI.

Access Reviews & Recertification¶

Quarterly reviews of all users with PHI-capable roles; remove stale entitlements.
JIT access for elevated roles (time-bound, ticket-linked); automatic expiry & reminders.
Evidence: access review reports, approval tickets, revocation logs.

Logging & Accountability¶

Meta-audit entries for each PHI read:
- who, when, tenant, purpose, filters applied, fields returned (class), clearance level, decision_id.
Chain-of-custody for exports: reason code, approver, signed manifest.

Log example (NDJSON)

{"ts":"2025-10-30T09:12:44Z","actor":"alice@tenant","tenant":"tn-42",
 "purpose":"treatment","decision":"allow","fields":["PHI.masked","Internal"],
 "scope":{"site":"denver","careTeam":["p-10021","p-10044"]},"decision_id":"dec-9af1"}

Training & Awareness¶

Onboarding module: minimum-necessary scenarios, role vs. purpose, break-glass rules.
Annual refresher with case studies (access exceptions, DSAR conflicts, incident learnings).
Attestations stored in evidence repository.

Break-Glass (Emergency Access)¶

Strictly exceptional; requires dual-approval or retroactive approval within SLA.
Time-boxed token (e.g., 60 minutes), full PHI allowed only for declared emergency.
Auto-logged with reason, incident/ticket link, and post-event review.

KPIs & Controls¶

phi.access.rate_masked ≥ 95% for non-treatment purposes
access.recertification.completion = 100% (quarterly)
breakglass.rate ≤ 0.5% of PHI reads, all with post-hoc review
orphan.entitlements = 0 after each recert cycle

Cross-references

platform/pii-redaction-classification.md (masking/tokenization) · platform/security-compliance.md (§Least Privilege, §Incident Response) · platform/data-residency-retention.md (§Residency-aware access)

HIPAA: Breach Notification Rule¶

Goal: Define how ATP, acting as a Business Associate (BA), detects, assesses, and supports notification for any breach of unsecured PHI in accordance with HIPAA Subpart D.

Definition & Scope¶

Breach: An impermissible acquisition, access, use, or disclosure of unsecured PHI that compromises its security or privacy.
Unsecured PHI: PHI that is not rendered unusable, unreadable, or indecipherable (e.g., not encrypted per HHS guidance). If PHI was properly encrypted at rest and in transit and keys remained protected, notification is typically not required (encryption safe harbor).

Discovery & Timers¶

Discovery date: When the breach is known or reasonably should have been known to ATP (or its agents).
Clock start: Breach-response timelines begin at discovery.

Notification Obligations (who/when)¶

To covered entity (ATP’s customer): ATP notifies without unreasonable delay and per BAA (e.g., within 5 business days), providing facts needed for downstream notifications.
To affected individuals (by covered entity): Without unreasonable delay and no later than 60 days after discovery; written notice (mail/email) with incident details and mitigation steps.
To HHS (by covered entity):
- ≥ 500 individuals (in a single state/jurisdiction): Within 60 days of discovery.
- < 500 individuals: Log and report to HHS no later than 60 days after the end of the calendar year in which the breach was discovered.
Media notice (by covered entity): If ≥ 500 individuals in a state/jurisdiction, notify prominent media within 60 days.

ATP supports customers’ notification duties by delivering timely incident facts, scope, and artifacts; ATP does not directly notify individuals unless contractually required.

Assessment & Decision¶

Four-factor risk assessment (documented):
1. Nature/extent of PHI (identifiers involved, likelihood of re-identification).
2. Unauthorized person who used/received the PHI.
3. Whether PHI was actually acquired or viewed.
4. Mitigation (e.g., recipient attestation of destruction, secure deletion).
Outcome: If low probability of compromise is not demonstrated, treat as breach → notify per above.

Standard Workflow¶

Detect & contain — Alert triage, isolate systems, revoke tokens/keys as needed.
Preserve evidence — Snapshots, logs, integrity proofs; maintain chain-of-custody.
Scope — Identify who/what/when, PHI elements, residency/regions, affected count.
Assess — Apply four-factor test; record rationale.
Notify — Covered entity per BAA SLA; support their individual/HHS/media notifications.
Remediate — Patch defects, rotate credentials/keys, strengthen controls.
Post-incident review — Root cause analysis, corrective actions, policy/ADR updates.

Required Notice Content (to individuals, prepared by covered entity; ATP supplies facts)¶

Description of what happened (including discovery date).
Types of PHI involved (e.g., name, DoB, diagnosis).
Steps individuals should take to protect themselves.
What the entity is doing to investigate, mitigate, and prevent recurrence.
Contact information for questions and assistance.

Breach Log & Evidence (maintained by ATP)¶

{
  "id": "BR-2025-0012",
  "discoveredAt": "2025-10-30T07:41:00Z",
  "actor": "service/ingestion-gw",
  "tenantId": "tn-42",
  "region": "US-CENTRAL",
  "phiElements": ["Name","MRN","Diagnosis"],
  "affectedCount": 612,
  "encrypted": false,
  "riskAssessment": {
    "natureExtent": "Direct identifiers + clinical",
    "unauthorizedRecipient": "External IP",
    "acquiredViewed": true,
    "mitigation": "Credentials rotated; IP blocked"
  },
  "decision": "breach",
  "notifications": {
    "coveredEntityNotifiedAt": "2025-10-30T12:00:00Z",
    "individualsRequired": true,
    "hhsRequired": true,
    "mediaRequired": true
  },
  "remediation": ["Patched WAF rule", "Rotated KMS keys", "Expanded ABAC"],
  "artifacts": ["logs/trace.ndjson","integrity/anchors.json","rca/BR-2025-0012.md"]
}

SLAs, KPIs & Controls¶

BA notification to covered entity: per BAA (target ≤ 5 business days).
Evidence pack ready: ≤ 3 business days from discovery.
RCA completion: ≤ 10 business days post-containment.
KPIs: breach.ba_notify.on_time ≥ 95%, rca.on_time ≥ 95%, repeat.incident.rate ↓.

Testing & Drills¶

Tabletop exercises (semi-annual): simulate PHI exfiltration scenario.
Evidence rehearsals: generate redacted notice content & artifact bundles.
Key rotations & access revocation drills tied to incident playbooks.

Cross-references

platform/security-compliance.md (§Incident Response & Forensics) · operations/observability.md (SIEM, alerting) · platform/pii-redaction-classification.md (minimization) · platform/data-residency-retention.md (residency-aware controls) · privacy-gdpr-hipaa-soc2.md (this doc)

HIPAA: Encryption & De-identification¶

Goal: Ensure PHI is rendered unusable to unauthorized parties and reduce privacy risk through standards-based encryption and disciplined de-/re-identification practices.

Encryption Safe Harbor (Summary)¶

If PHI is encrypted using industry-accepted algorithms and keys remain protected, incidents typically do not trigger notification obligations under HIPAA’s Breach Notification Rule (“encryption safe harbor”).
Scope: Both at rest and in transit; ensure keys are never stored with ciphertext and access is strictly controlled/audited.

ATP Encryption Controls¶

At rest (envelope encryption):
- Per-tenant CMK (customer-managed key) in region-scoped KMS/HSM.
- Per-object DEK (data encryption key) → DEK = AES-256-GCM (or equivalent); DEK encrypted (wrapped) by tenant CMK.
- Rotation: CMK rotation annual (or tenant policy), DEK rotation on segment rollover and on-demand (incident/key hygiene).
- Separation of duties: Key admins ≠ data admins; all key ops logged and reviewed.
In transit:
- TLS 1.3+ for client/API; mTLS for service-to-service.
- Strict cipher suites; certificate pinning (mesh) where supported; HSTS on edge.
Integrity & provenance:
- AES-GCM (AEAD) for authenticity; hash chains + anchors for record integrity.
- KMS audit trails cross-linked to meta-audit stream.
Operational safeguards:
- Key usage alarms (unusual decrypt frequency, cross-region calls).
- Break-glass keys disabled by default; enable only via dual-control, time-bound.

Key wrapping sketch

plaintext → [AES-256-GCM with DEK] → ciphertext
DEK → [Wrap with tenant CMK in KMS/HSM] → wrappedDEK
store: {ciphertext, wrappedDEK, aad: {tenantId, region, streamId, segmentId}}

De-identification Options¶

Safe Harbor (prescriptive): Remove 18 identifiers (names, geographic details below state, all elements of dates except year for dates directly related to an individual, phone/fax numbers, email, SSN, MRN, health plan numbers, account numbers, certificate/license numbers, vehicle/device identifiers, URLs/IPs, biometric identifiers, full-face photos, and any other unique identifying number/characteristic).
Expert Determination: Qualified expert applies statistical/technical methods and documents that the risk of re-identification is very small given context and controls.

Safe Harbor export checklist (sample)

exportMode: "HIPAA-SafeHarbor"
remove:
  - name
  - geographic_detail_below_state
  - all_dates_except_year
  - phone
  - fax
  - email
  - ssn
  - mrn
  - health_plan_beneficiary
  - account_number
  - certificate_license
  - vehicle_identifiers
  - device_identifiers
  - url
  - ip_address
  - biometric_identifiers
  - full_face_photos
  - other_unique_identifiers
evidence:
  manifestSigned: true
  policyVersion: "atp-export-policy-2025.1"

Pseudonymization & Tokenization (Not De-identification)¶

Pseudonymization: Replace direct identifiers with derived pseudonyms (reversible within tenant using keys/maps). Reduces risk but still PHI.
Tokenization (FPE or vault-based): Reversible with token vault/KMS; preserves format for analytics/joins.
ATP usage: Prefer pseudonymize subject identifiers in non-essential audit fields; keep raw only where legally/operationally required and always encrypted.

Tenant-scoped pseudonym (deterministic)

pseudonym = HMAC-SHA256(tenantSalt, subjectIdentifier)
# tenantSalt is derived from a tenant-scoped KMS key; rotation triggers re-key jobs

Example — selective pseudonymization policy (YAML)

policyId: "phi-pseudo-v1"
fields:
  patientId:
    action: pseudonymize
    method: HMAC-SHA256
    keyRef: kms:tenants/{tenantId}/keys/pseudo
  clinicianEmail:
    action: mask
    params: { showFirst: 1, showLast: 1, preserveDomain: true }
  visitDateTime:
    action: generalize
    params: { granularity: "day" }
evidence:
  version: 1
  effectiveFromUtc: 2025-01-01T00:00:00Z

Export & Query Modes¶

Treatment/Operations (minimum necessary): Return masked/tokenized PHI by default; reveal only with appropriate purpose + clearance claims.
Research/analytics: Use pseudonymized/tokenized data sets; Safe Harbor exports for external sharing.
E-discovery/DSAR: Apply residency + retention + redaction policies; attach signed manifest enumerating transformations (mask, drop, pseudonymize).

Evidence & Verification¶

Encryption coverage: encryption.at_rest=100%, tls.enforced=100%.
Key management: Rotation logs, KMS access logs, HSM attestation.
Export proofs: Safe Harbor checklist + manifest, expert’s determination report (if used).
Monitoring: Alerts on unencrypted asset creation, key misuse, policy drift.

Risks & Residual Controls¶

Re-identification risk: Even pseudonymized datasets can be linkable; mitigate by generalization, suppression, and access constraints.
Key custody risk: Enforce dual-control, JIT key access, and regional CMK pinning.
Process drift: CI policy gates block deployments that reduce encryption or alter export modes without DPIA/DPO sign-off.

Cross-references

platform/data-residency-retention.md (§Encryption & Keying, §Exports) · platform/pii-redaction-classification.md (masking/tokenization) · platform/security-compliance.md (controls, incident response) · privacy-gdpr-hipaa-soc2.md (this doc)

SOC 2: System Description & Boundaries¶

Goal: Provide auditors a clear, versioned description of ATP’s system, scope, and responsibilities to support SOC 2 Type II attestation.

System Description (high level)¶

Core services
- Audit Gateway (edge API/WAF/rate-limit) → request admission, schema/tenant validation.
- Ingestion → normalization, classification hints, write-time redaction, enqueue.
- Policy/Guards → tenancy/residency/ABAC/OPA enforcement.
- Integrity & Ledger → segmenting, hash-chaining, anchoring, seal/verify.
- Storage → region-scoped object/columnar stores and indices; WORM semantics.
- Projection/Query → read models, residency-aware filtering, redaction-on-read.
- Export & eDiscovery → DSAR, legal, and auditor exports with signed manifests.
- Control Plane → tenant catalog, editions/entitlements, KMS bindings, config.
- Observability → logs/metrics/traces, SIEM feed, security events.
- CI/CD & Release → build, SBOM, SAST/DAST, deploy gates, change records.
Infrastructure & topology (representative)
- Cloud: multi-region VNets, private endpoints, service mesh (mTLS), API Gateway/WAF.
- Data: object storage (append/WORM classes), relational/columnar index, queue bus, cache.
- Keys: region-scoped KMS/HSM; per-tenant CMKs; envelope encryption.
- Network: no public east-west; egress allowlists; peered VNets by region.
Primary data flows
1. Append path: Producer → Gateway → Ingestion → Policy → Queue → Ledger/Storage → Anchor.
2. Query path: Client → Query API → ABAC/Residency → Redaction → Result.
3. Export path: Request → Guard checks → Residency-compliant route → Manifest/sign → Delivery.
4. Ops path: Backup → Verify → Store (WORM) → Restore drills → Evidence.
5. DR path: Replicate (policy-bound) → Failover/read-only posture → Cutback.

flowchart LR
  P[Producers/Tenant Apps] -->|TLS+JWT| Gw["Audit Gateway (WAF/Rate-limit)"]
  Gw --> Ing[Ingestion & Policy Guards]
  Ing --> Q[Queue/Bus]
  Q --> Led[Integrity & Ledger]
  Led --> Obj[(Region Object Store)]
  Led --> Idx[(Regional Index)]
  Qry[Query API] -->|ABAC/Residency| Idx
  Idx --> Qry
  Exp[Export/eDiscovery] -->|Guards+Manifests| Obj
  KMS[(KMS/HSM)] --- Led
  Obs[Observability/SIEM] --- Gw
  Obs --- Ing
  Obs --- Qry

Hold "Alt" / "Option" to enable pan & zoom

Boundaries (scope statement)¶

In-scope (managed by ATP)
- Application services listed above; configuration and operation of ATP-run cloud resources.
- Security controls: identity/authorization within ATP, encryption, residency/retention enforcement.
- Build/deploy pipeline, vulnerability management, logging/monitoring for ATP components.
- Evidence generation: integrity anchors, audit logs, control execution records.
Out-of-scope (customer/cloud responsibilities)
- Tenant applications and their internal security practices.
- End-user devices and tenant corporate networks.
- Underlying cloud IaaS physical controls (covered by provider SOC reports).
- Tenant identity providers and user lifecycle outside of ATP’s boundaries.

Principal Service Commitments¶

Availability: Regional redundancy and failover; published SLA targets; tested RPO/RTO.
Security: Defense-in-depth, least privilege, SIEM-integrated detection, secure SDLC.
Confidentiality: Encryption in transit/at rest (per-tenant CMKs); ABAC; policy-as-code guards.
Processing Integrity: Append-only ledger, hash-chains, periodic verification, idempotent ingest.
Privacy: PII classification/redaction; DSAR/exports; residency enforcement and retention controls.

Complementary User-Entity Controls (CUECs)¶

Tenants must:

Enforce MFA and timely access reviews in their IdP; revoke credentials promptly.
Protect API credentials/keys and rotate per policy; scope tokens to least privilege.
Provide accurate classification hints and avoid logging unnecessary PII/PHI.
Maintain secure producer environments and network egress to ATP endpoints.
Confirm exports are handled in compliant environments and retain chain-of-custody.

Versioning & Updates¶

The System Description is versioned per audit period; maintained alongside ADRs and diagrams.
Material changes (architecture, data flows, residency posture, processors) trigger an interim update and risk assessment (DPIA where applicable).
A change log and diff summary are delivered to auditors at observation start and on material change.

Evidence Artifacts¶

Versioned System Description (this section), C4/C3 diagrams, component/service inventory.
Network/data flow diagrams; data classification & residency matrices.
Service commitments & CUECs document; mapping to TSC categories.
Links to ADRs, runbooks, test results (DR drills, integrity verification, vulnerability scans).

Cross-references

security-compliance.md (Security Architecture, Threat Model) · data-residency-retention.md (Residency/DR) · pii-redaction-classification.md (Privacy controls) · deployment-views.md (Topology & ops) · context-map.md (Component relationships)

SOC 2: Management Assertions & Type II Testing¶

Goal: Establish how ATP makes formal management assertions and demonstrates operating effectiveness of controls over the observation period for SOC 2 Type II.

Overview¶

Type I: Point-in-time design suitability of controls.
Type II: Operating effectiveness across an observation window (6–12 months), with evidence that controls worked as designed.

Management Assertions (What we attest)¶

Design: Controls are suitably designed to meet applicable Trust Services Criteria (Security, plus Availability/PI/Confidentiality/Privacy as elected).
Operation: Controls operated effectively throughout the observation period.
Boundaries: The system description is accurate and fairly presents ATP’s services and boundaries.
Commitments: Service commitments and system requirements were met or exceptions are disclosed with remediation plans.

Sample assertion excerpt

Management asserts that, based on the criteria described in the AICPA Trust Services Criteria,
(1) the system was suitably designed and implemented throughout 2025-01-01 to 2025-12-31,
(2) the controls stated in the accompanying description were effective to provide reasonable assurance
that the service commitments and system requirements were achieved.

Auditor Testing Approach (What they do)¶

Sampling of control executions (e.g., 25 MFA logins, 20 change approvals, 4 DR drills).
Evidence inspection: logs, tickets, ADRs, screenshots, configuration exports.
Re-performance: auditor independently executes/read-only tests (e.g., verify encryption settings).
Interviews with control owners and walkthroughs of key processes.

Evidence Strategy (What we prepare)¶

Control register with: Control ID, TSC mapping, owner, intended frequency, evidence source, and query/collection method.
Automated pulls from SIEM/CMDB/CI: MFA events, key rotations, change approvals, backup verification, DR drill results.
Attestations: training completion, access review sign-offs, incident PIRs.
Linkage: Each evidence item includes control ID, date, owner, and immutable artifact (hash or signature).

Control sampling table (example)

Control ID	TSC	Control	Evidence Source	Sample Size	Cadence
CC6.6	Security	MFA for admin ops	Auth logs (SIEM)	25 events / qtr	Quarterly
CC7.2	Security	Immutable audit logs	Ledger anchors, WORM store proofs	Continuous	Monthly package
A1.3	Availability	Regional failover drilled	DR runbook, drill report, tickets	2 drills	Semi-annual
PI1.2	Proc. Integrity	Hash-chain verification	Verification job output	12 runs	Monthly

Exceptions & Remediation¶

Exception types: design gap, missed execution, partial evidence, timing deviation.
Documentation: auditor records exception; ATP provides root cause, impact, compensating controls, remediation plan with target date.
Tracking: exceptions tracked in the risk register; remediation linked to ADRs and change tickets; closure evidence packaged for auditor.

Exception log (sample NDJSON)

{"id":"SOC2-EX-2025-07","controlId":"CC6.1","date":"2025-07-12",
 "type":"missed-execution","desc":"1 of 4 quarterly access reviews closed 5 days late",
 "impact":"low","compensating":"JIT entitlement expiry + detective alerts",
 "remediation":"Adjust reviewer alternates; add calendar guardrail",
 "targetClose":"2025-08-15","owner":"Identity"}

Timeline & Cadence¶

Observation window: agreed with auditor (e.g., 12 months).
Quarterly checkpoints: internal evidence refresh, exception triage, control health review.
Bridge letters: issued between periods if needed to represent no material changes since last report.
Freeze points: code/config freeze snapshots for major scope boundaries (system description version tags).

Roles & Responsibilities (RACI)¶

Control Owners (R): Execute controls, retain evidence, respond to samples.
Compliance Lead (A): Owns SOC program, approves assertions, coordinates audit.
SRE/Security/Platform (C): Provide technical evidence, attend walkthroughs.
Legal/DPO (C): Review privacy/residency statements; align with DPAs/BAAs.
Auditor (I): Independent testing and reporting.

KPIs & Quality Gates¶

evidence.on_time ≥ 95% (per sampling request)
exceptions.remediated.on_time ≥ 95%
controls.automation.coverage ≥ 80% (automated evidence vs manual)
findings.repeat.rate = 0 (no repeat of prior-period exceptions)

Deliverables to Auditor¶

System Description (versioned), Control Matrix, Evidence Index, Exception Register, Management Assertion Letter.
Read-only access to evidence repositories; time-bound credentials; export manifests signed and hashed.

Cross-references

privacy-gdpr-hipaa-soc2.md (§SOC 2 Overview, §TSC Mapping) · security-compliance.md (§Control Framework, §Incident Response) · deployment-views.md (topology) · data-residency-retention.md (residency/retention controls)

SOC 2: Subservice Organizations (Cloud Providers)¶

Goal: Define how ATP relies on cloud and other subservice providers for control objectives, how that reliance is governed, and what evidence we keep for SOC 2.

Approach¶

Default stance: Carve-out — controls operated by cloud providers are excluded from ATP’s scope; auditor relies on the provider’s SOC 2 Type II (and/or ISO 27001) reports.
Providers in scope of reliance: Azure (primary), optional AWS (DR/secondary). Additional providers (DNS, CDN/WAF, email/SMS, artifact registry, HSM/KMS) are maintained in the Subprocessor Register.
When we’d consider inclusive: Only in exceptional cases where ATP designs/operates a material portion of a provider control and can produce direct evidence (rare; requires auditor buy-in).

Carve-out vs Inclusive (Summary)¶

Dimension	Carve-out (ATP Default)	Inclusive (Exception)
Evidence	Provider SOC 2 / ISO reports, bridge letters	ATP + provider evidence in-scope
Responsibility	Provider runs the control	ATP co-owns the control operation
Audit Effort	Lower for ATP; TPRM heavy	Higher; joint testing/walkthroughs
Use Cases	IaaS physical, data center, core platform controls	Managed services with ATP-run control logic

Third-Party Risk Management (TPRM)¶

Annual review of each provider’s SOC 2 Type II (and/or ISO 27001) report; obtain bridge letters covering any gaps between report end and current date.
Gap analysis for noted exceptions; record compensating controls (e.g., additional encryption attestations, monitoring).
SLAs/DPAs/BAAs verified for: availability, breach notification windows, data location, subprocessor change notice, encryption commitments, incident cooperation.
Issue tracking: Findings logged in the risk register with owners, remediation targets, and evidence of closure.

Complementary Subservice Organization Controls (CSOCs)¶

ATP assumes the following provider controls are effective (per their report):

Physical security, environmental controls, and infrastructure patching.
Hypervisor isolation, hardware lifecycle, media sanitization.
Platform identity boundary (cloud IAM primitives) and KMS durability.

ATP implements complementary user-entity controls on our side:

Strong tenancy isolation on top of cloud IAM; mTLS mesh; egress allowlists.
Per-tenant CMKs with envelope encryption; key usage alarms and rotation.
Residency pinning (no cross-region replication unless policy-approved).
Continuous SIEM ingestion of cloud logs (config, KMS, network) and drift alerts.

Contractual & Governance Requirements¶

Contracts must include: SOC 2 attestation, breach notice SLAs, data residency options, subprocessor change notifications, uptime SLAs, and right to receive assurance reports.
Change management: Adding/replacing a cloud region/provider triggers system description update, ROPA/DPIA review (GDPR), and auditor notification at next checkpoint.

Evidence Artifacts¶

Subprocessor Register (name, services, data types, regions, contact).
Latest SOC 2 / ISO reports + bridge letters; provider pen-test summaries if available.
Gap analysis with mitigations; ticket links for follow-ups.
Contract excerpts: SLA, DPA/BAA, residency clauses, security addenda.
Cloud config baselines (IaC snapshots), KMS key inventories, and egress policies.

Review checklist (sample)

pro

href="#__codelineno-24-1">reviewId: "tpra-2025-q1" viders: - name: Azure reports: soc2TypeII: 2024-10-31 iso27001: 2024-10-31 bridgeLetter: 2025-01-31 regions: [EU, US] dataTypes: [audit_records, keys_wrapped, backups] gaps: [] - name: DNS/CDN reports: soc2TypeII: 2024-09-30 bridgeLetter: 2025-01-31 gaps: - id: "G-001" desc: Minor exception in change approvals mitigation: Extra edge WAF rule approvals; monthly spot checks owner: "Platform"

Risks & Mitigations¶

Provider outage / SLA miss: Multi-region architecture, read-only failover, clear RPO/RTO; DR drills with evidence.
Residency drift: IaC guards + policy-as-code; alerts on cross-region resources.
Assurance report delay: Interim bridge letter required; escalate via vendor management; consider temporary compensating controls.

Cross-references

security-compliance.md (Control Framework, Vendor Security) · deployment-views.md (Regional topology) · data-residency-retention.md (Residency, DR) · privacy-gdpr-hipaa-soc2.md (§Evidence, §TSC Mapping)

Continuous Monitoring & Automated Compliance¶

Goal: Prove—continuously—that controls are configured and operating as intended. Turn policies into code, surface posture in real time, and fail fast when drift or regressions appear.

Real-Time Dashboards¶

Framework posture: GDPR / HIPAA / SOC 2 compliance scorecards per tenant, region, and environment.
Control health: Live status for encryption, access reviews, DR drills, retention purges, classification rates.
Evidence freshness: Indicators for last successful collection (e.g., “KMS rotation evidence: 27m ago”).
Drill-downs: From framework → criterion → control → evidence item (immutable link + hash).

Automated Checks (Controls-as-Code)¶

Encryption validation: Verify at-rest encryption enabled with per-tenant CMKs and TLS 1.3+ on all endpoints.
Access control tests: RBAC/ABAC evaluations (sample JWTs) and least-privilege scans on service principals.
Retention enforcement: Dry-run & executed purge windows, legal-hold overrides honored, signed purge manifests.
Integrity jobs: Hash-chain verification cadence; alert on missing segments/anchors.
Backup/DR: Backup integrity checksums, restore rehearsals, RPO/RTO window assertions.

Control definition (example)

id: ENC-ATREST-001
frameworks: [SOC2.C, GDPR.Art32, HIPAA.Security]
title: "All data at rest is encrypted with tenant-scoped CMKs"
evaluate:
  kind: "IaC+CloudAPI"
  queries:
    - az: "storage accounts | where properties.encryption.keyType == 'Account' => FAIL"
    - az: "keyvault keys | where rotation.enabled != true => WARN"
evidence:
  sources: ["Azure Resource Graph", "KMS audit logs"]
  artifactRetention: P1Y
thresholds:
  failOn: ["storage:unencrypted", "cmk:missing"]
  warnOn: ["rotation:disabled"]

Policy-as-Code (OPA/Rego) + CI/CD Gates¶

Rego rules encode GDPR/HIPAA/SOC2 requirements; evaluated in CI and periodically in prod.
Pipelines block non-compliant changes (IaC, app config, policies) with human-readable reasons.
Change tickets require control impact tags; ADRs link to passing policy bundles.

Rego snippet — encryption at rest required

package controls.encryption

deny[msg] {
  input.resource.kind == "StorageAccount"
  not input.resource.properties.encryption.enabled
  msg := sprintf("Encryption at rest disabled for %s", [input.resource.name])
}

deny[msg] {
  input.resource.kind == "StorageAccount"
  input.resource.properties.encryption.keySource != "Microsoft.Keyvault"
  msg := sprintf("Storage %s not using tenant-scoped CMK", [input.resource.name])
}

Drift Detection & Auto-Remediation¶

Config diffing: Detect deviations from approved baselines (IaC state vs. live cloud).
Residency guards: Alert if data stores or backups appear in non-approved regions; block exports automatically.
Auto-fix playbooks: Optional remediation (re-enable TLS enforcement, re-apply WORM policy) with approval workflow.
Forensics capture: On drift, take a config snapshot, hash it, store in evidence vault.

Drift rule (YAML)

ruleId: RES-REGION-DRIFT
match: "storage.*"
assert:
  allowedRegions: ["EU", "US"]
actions:
  onFail:
    - block: "export_service"
    - notify: ["compliance@connectsoft.ai", "sre@connectsoft.ai"]
    - recordEvidence: true

Metrics & KPIs¶

Compliance score (per framework): weighted pass rate of mapped controls.
Control pass/fail rates: trend lines; MTTR for failed controls.
Evidence freshness: max age per evidence type (e.g., access review attestations ≤ 90 days).
Drift rate: number of drift events per 30 days; auto-remediated vs manual.
Coverage: % controls enforced by policy-as-code vs procedural.

Score computation (illustrative)

score_framework = Σ(weight_i * pass_i) / Σ(weight_i)
where pass_i ∈ {1=pass, 0.5=warn, 0=fail}

Evidence Packaging & Reporting¶

Immutable manifests: SHA-256 of each artifact; signer identity; policy version; collection timestamp.
Scheduled bundles: Monthly SOC 2 evidence pack; quarterly GDPR/HIPAA posture report.
Auditor access: Read-only portal/API with time-bound credentials and watermarking.

Cross-references

security-compliance.md (§Security Monitoring & Detection, §Control Framework) · data-residency-retention.md (§Observability & Compliance Evidence) · pii-redaction-classification.md (§Testing & Validation) · deployment-views.md (Ops dashboards)

Privacy Training & Awareness¶

Goal: Build organization-wide privacy fluency and provable control effectiveness across GDPR, HIPAA, and SOC 2 via onboarding, annual refreshers, role-specific curricula, and continuous drills.

Scope & Audience¶

All personnel with any ATP access (employees, contractors).
Elevated roles: production access, DPO/Security, SRE/On-call, Developers, Support/Success, Sales/CS.

Curriculum (what everyone must know)¶

Core (all-hands): Privacy principles (minimization, purpose, rights), data handling do/don’t, residency basics, incident reporting, phishing awareness.
Role-specific tracks:
- Developers: secure coding for PII/PHI, classification/redaction, secrets, logs hygiene, DSAR-safe data shapes.
- SRE/On-call: incident/breach playbooks, chain-of-custody, DR with residency constraints, evidence capture.
- Support/Success: identity verification, DSAR intake & SLA, least-privilege data access, export manifests.
- Security/DPO: DPIA/ROPA workflows, vendor privacy reviews, regulator comms, exception handling.
- Sales/CS/PM: commitments vs capabilities, CUECs, lawful basis registry, customer data in demos.

Matrix (excerpt)

Role	Required Modules
All personnel	Privacy 101, Incident Reporting, Phishing
Developer	PII/PHI Handling, Redaction APIs, Secrets & Logs
SRE	Breach Response, DR/Residency, Evidence Packs
Support	DSAR Intake, Identity Verification, Export Safety

Cadence & SLAs¶

Onboarding: complete within 30 days of start (access to prod data blocked until completion).
Annual refresher: by anniversary; auto-enrolled; updates on regulatory changes & incidents.
Role change: delta training within 14 days.
Remedial: required after policy violations or phishing failures (≤ 10 business days).

Delivery & Records¶

LMS hosts modules, quizzes (pass ≥ 80%), attestations, and versioned content.
Evidence store: immutable CSV/PDF exports + signed manifest (training id, module/version, score, timestamp).
Retention: training records ≥ 2 years (or longer per framework/customer contract).

Simulations & Drills¶

Phishing simulations: quarterly; targeted remediation for failures; trend tracked.
Tabletops: breach (GDPR/HIPAA overlays) semi-annual; DSAR dry-runs quarterly; export/redaction spot checks monthly.
After-action: CAPA items logged; policy and content updated as needed.

Automation & Gates¶

Access gate: production roles require training.compliant=true claim (issued by LMS sync).
Policy-as-code: CI blocks merges to sensitive repos if author’s training is stale; JIT elevation denied if refresher overdue.

OPA/Rego (sketch)

package atp.training

deny[msg] {
  input.request.action == "elevate"
  not input.actor.claims.training.compliant
  msg := "Denied: training not current for elevation request"
}

Metrics & Targets¶

training.completion.rate = 100% (onboarding & annual)
training.on_time.rate ≥ 98%
phishing.fail.rate ↓ QoQ (target: < 5%)
tabletop.breach.completed = 2/yr, dsar.dryrun.completed = 4/yr
remedial.within_sla.rate ≥ 95%

Evidence (auditor-ready)¶

LMS exports (completion, scores, attestations) with signed manifest.
Simulation reports (campaign results, remediation).
Tabletop agendas, attendance, findings, CAPA tracking.
Policy versions & change logs tied to incident learnings.

Quick policy excerpt (YAML)¶

training:
  onboardingDeadlineDays: 30
  annualRefresher: true
  roleChangeDeltaDays: 14
  gates:
    requireForProdAccess: true
    requireForJitElevation: true
  phishing:
    cadence: quarterly
    remedialWindowDays: 10
evidence:
  lmsExport: required
  manifest: signed
  retention: P2Y

Cross-references: security-compliance.md (§Incident Response, §Control Framework) · pii-redaction-classification.md (masking & handling) · data-residency-retention.md (residency constraints) · operations/observability.md (dashboards & KPIs)

Done when

LMS courses live for all roles; access gates enforced.
Dashboards show real-time completion/overdue and simulation trends.
Evidence bundle generated monthly with manifests and links to CAPA.

Vendor & Third-Party Management¶

Goal: Ensure subprocessors and third-party services meet ATP’s privacy, security, and residency commitments through formal assessment, contracts, continuous monitoring, and exit verification.

Third-Party Risk Management (TPRM) Lifecycle¶

Intake & Scoping
- Determine data categories (PII/PHI), processing purpose, regions, and criticality (SLA impact).
- Assign provisional risk tier (Critical / High / Medium / Low).
Assessment
- Security & privacy questionnaire (SIG-lite or equivalent).
- Review SOC 2 Type II / ISO 27001 (and HIPAA/HITRUST where applicable) + bridge letter.
- Validate residency controls, encryption, incident SLAs, subprocessor notifications.
Contracting
- Execute DPA (GDPR) and BAA (HIPAA, if PHI).
- Embed security addendum: breach windows, encryption requirements, data return/deletion, audit rights, change-notice SLAs.
Onboarding Controls
- Create vendor entry in Subprocessor Register (public customer-facing list).
- Tag systems/flows that call the vendor; enforce egress allowlists and scope-limited credentials.
Monitoring
- Annual reviews (or more frequent for Critical): re-assess reports, exceptions, remediation progress.
- Continuous drift checks (region pinning, egress policy, key usage alarms).
- Track vendor incidents; validate notification timeliness and cooperation.
Offboarding / Exit
- Verify data return/deletion (certificate of destruction or logs).
- Revoke access, rotate keys, update allowlists, remove from register.
- Capture evidence bundle and close the risk item.

Subprocessor Register (excerpt)¶

Name	Role	Data Types	Regions	DPA/BAA	Latest Report	Risk	Next Review
Azure	IaaS/PaaS	audit_records, backups	EU, US	DPA ✓ / BAA ✓	SOC2-II 2024 + bridge	Critical	2025-10-31
CDN/WAF	Edge protection	IPs, request metadata	EU, US	DPA ✓ / BAA n/a	SOC2-II 2024	High	2025-09-30
Email/SMS	Notifications	email/phone (Sensitive)	EU (primary)	DPA ✓ / BAA n/a	ISO27001 2024	Medium	2025-07-15

Public disclosure: Provide a sanitized version of this register to customers; change-notice cadence aligned to contracts.

Vendor Entry (policy-as-code, YAML)¶

vendor:
  name: "Contoso CDN"
  tier: "High"
  services: ["cdn","waf"]
  dataCategories: ["Personal","Sensitive"]
  regionsAllowed: ["EU","US"]
  contracts:
    dpa: true
    baa: false
    breachNoticeDays: 5
    subprocessorChangeNoticeDays: 30
  assurance:
    soc2Type: "Type II"
    soc2PeriodEnd: "2024-09-30"
    bridgeLetter: "2025-01-31"
    iso27001: true
  controls:
    encryptionAtRest: "Provider CMK or ATP TLS tunnel"
    encryptionInTransit: "TLS1.3+"
    residencyPinned: true
  evidenceSources:
    - "SOC2 report (portal)"
    - "ISO certificate"
    - "Pen-test summary"
  owners:
    business: "Platform PM"
    security: "TPRM Lead"
  review:
    frequency: "Annual"
    nextDue: "2025-09-30"

Evaluation Matrix (scoring sketch)¶

Criterion	Weight	Examples of Pass Evidence
Security attestations	0.25	SOC2-II within 12m; bridge letter; ISO 27001
Privacy & contracts	0.20	DPA/BAA signed; SCCs/TIA on transfers
Residency & egress	0.20	Region pinning, no cross-border by default
Incident & breach SLAs	0.15	≤ 72h GDPR DPA notice; ≤ 5 days HIPAA BAA
Encryption & keying	0.10	At-rest + in-transit; KMS/HSM usage
Operations posture	0.10	DR, RPO/RTO, uptime SLA, change controls

Decision rule: approve if score ≥ 0.8, conditional approve 0.7–0.79 with compensating controls, otherwise reject.

Automated Gates & Checks¶

CI/IaC gate: block deployment if a referenced vendor is missing DPA/BAA or assurance expired.
OPA/Rego policy (sketch):

package tprm.vendor

deny[msg] {
  input.deploy.references[vendor]
  not input.vendor[vendor].contracts.dpa
  msg := sprintf("Vendor %s missing GDPR DPA", [vendor])
}
deny[msg] {
  input.deploy.references[vendor]
  now := time.now_ns()
  end := time.parse_rfc3339_ns(input.vendor[vendor].assurance.soc2PeriodEnd)
  time.diff(now, end).months > 12
  msg := sprintf("Vendor %s SOC2 report stale >12m", [vendor])
}

Exit Checklist¶

Access revoked (API keys rotated, IP allowlists pruned).
Data export to tenant or ATP archive (as contracted).
Deletion certificate or provider log evidence received.
Subprocessor register updated; customers notified if required.
Evidence bundle finalized (hash, signer, timestamp).

Metrics & Targets¶

vendors.reviewed.on_time ≥ 95%
assurance.stale.rate = 0
contracts.with.DPA = 100% (where GDPR applies)
contracts.with.BAA = 100% (where HIPAA applies)
vendor.incident.notice.SLA.met ≥ 99%

Cross-references

security-compliance.md (§Third-Party & Supply Chain Security, §Control Framework) · privacy-gdpr-hipaa-soc2.md (§SOC 2 Subservice Organizations) · data-residency-retention.md (§Residency & Egress) · operations/observability.md (compliance dashboards)

Goal: Permit transfers only when lawful, necessary, and provably safeguarded. Default to in-region processing; fail closed on uncertainty.

Transfer Bases¶

Adequacy decisions: Transfers to countries recognized by the EU as adequate (e.g., UK, Japan) allowed when residency policy permits and contracts reflect the destination.
Standard Contractual Clauses (SCCs): For non-adequate countries, use EU Commission SCCs with the correct module (C→P, P→P, C→C) + Annexes describing ATP data, purposes, and technical measures.
Supplementary measures: Strong encryption with EU-resident KMS keys, pseudonymization before export, data minimization, access transparency & audit, and strict purpose binding.
No transfer by design: If tenant policy requires EU-only, cross-region replication/export is denied; DR outside the region operates read-only until policy approval (see data-residency-retention.md).

Transfer Impact Assessment (TIA)¶

When required: Any SCC-based transfer or material change in destination vendor, route, or data class.
Method:
1. Map flows (data classes, subjects, volumes, processors/subprocessors).
2. Assess laws & practices in destination (access by public authorities, redress).
3. Evaluate measures (crypto, keys, pseudonymization, contractual limits).
4. Decide residual risk (Accept / Accept with compensating controls / Reject).
5. Record & sign (DPO + security); set review date (at least annually or on change).
Evidence: Signed TIA, SCC set + Annexes, list of supplementary measures, next review date.

Implementation & Controls¶

Residency engine: Enforces region pins on storage, backups, and exports; blocks egress to non-allowed regions.
Egress control: Layer-7 allowlists by FQDN/IP; DNS policies prevent resolution to non-approved regions.
Key management: Split-knowledge KMS; keys remain in the source region (e.g., EU). Services outside region can never unwrap plaintext.
Export service: Requires a lawful basis tag (adequacy|scc) and a policy bundle id (TIA/SCC manifest) per job; jobs without both are rejected.
Fail-closed posture: If adequacy list or SCC manifests are stale, transfers are halted until refreshed.

Decision Table (summary)¶

Destination	Residency Policy	Lawful Basis	Outcome
Adequate country	Allows transfer	Contract updated	Allow (log + manifest)
Non-adequate	Allows transfer	SCCs + TIA + measures	Allow with safeguards
Any	EU-only	n/a	Block (emit `ResidencyViolation`)
Non-adequate	Allows transfer	Missing SCC/TIA	Block (request remediation)

Policy-as-Code (YAML sketch)¶

transfers:
  adequacyCountries: ["UK","JP","NZ","CA", "ADDITIVE-LIST"]
  requireSccForNonAdequate: true
  supplementaryMeasures:
    - encryption: "AES-256 + EU-KMS"
    - pseudonymization: "tenant-salted HMAC for identifiers"
    - purposeBinding: true
  residency:
    default: "EU"
    euOnlyTenants:
      - "tenant-123"
  evidence:
    require:
      - "scc.manifestId"
      - "tia.documentId"
    refreshMaxAge: "P12M"

OPA/Rego Guard (export gate, sketch)¶

package residency.transfer

deny[msg] {
  input.job.type == "export"
  input.job.tenant.euOnly == true
  input.job.destination.region != "EU"
  msg := "EU-only tenant: cross-border export denied"
}

deny[msg] {
  input.job.type == "export"
  not input.job.destination.country in input.policy.adequacyCountries
  not input.job.evidence.scc.manifestId
  msg := "Non-adequate destination requires SCC manifest"
}

deny[msg] {
  input.job.type == "export"
  input.job.requiresSupplementaryMeasures
  not input.job.controls.kms.regionScopedEU
  msg := "Supplementary measure missing: EU-scoped KMS"
}

Documentation & Registers¶

DPAs: Reference adequacy or SCC modules; include Annexes and supplementary measures.
TIA records: Stored in evidence vault with hash + signer; linked from export manifests.
Subprocessor register: Shows destination regions and transfer bases for each vendor.

Cross-references data-residency-retention.md (§Residency Model, §Replication & DR, §Observability & Compliance) · security-compliance.md (§Third-Party & Supply Chain, §Network & Boundary Controls) · privacy-gdpr-hipaa-soc2.md (§Vendor Management, §SOC 2 Subservice Orgs)

Accountability & Demonstrable Compliance¶

Goal: Make compliance provable at any moment with immutable evidence, clear ownership, and automated checks—so audits become a packaging exercise, not a scramble.

Evidence Operating Model¶

Documentation principle: If it’s not documented, it didn’t happen. Every control execution emits evidence (log, report, artifact) with timestamp, signer, and hash.
Central evidence vault: Versioned, WORM-capable storage for policies, ADRs, test results, audit logs, training records, incidents, DPAs/BAAs, TIAs/SCCs, DR drill reports.
Manifests: Each bundle (e.g., “Q1-GDPR-Evidence”) has a signed manifest listing artifacts, SHA-256 hashes, origin, and retention period.
Chain-of-custody: Movement of sensitive evidence (e.g., incident forensics) recorded in meta-audit with who/when/why.

Versioning & Governance¶

Policy lifecycle: Draft → Review (DPO/Security) → Approved → Effective; all changes require PR + approver signatures.
Traceability: Every evidence artifact links to the control ID, framework clause(s), and ADR (when architectural).
Retention of records: Evidence retained per framework or contract (min. 2 years; longer for HIPAA/SOC 2 observation periods).

Automation & “Fail-Closed” Gates¶

Evidence freshness checks: Pipelines verify that required artifacts are present and not stale (e.g., SOC2 bridge ≤ 12 months).
Release gates: Production releases that would change security posture are blocked if impacted controls lack current evidence.
Self-serve auditor packs: On demand, generate framework-scoped ZIPs (GDPR/HIPAA/SOC2) with manifests, plus redacted variants.

Policy-as-code (YAML sketch)

evidence:
  bundles:
    - id: "gdpr-q1-2025"
      controlsRequired: ["Art5","Art30","Art32","Breach33","Residency"]
      maxArtifactAge:
        policyDocs: "P12M"
        incidentRunbook: "P6M"
        drDrillReport: "P3M"
      manifest:
        signed: true
        hashing: "SHA-256"
  retention:
    default: "P2Y"
    hipaaIncidents: "P6Y"
    soc2Period: "P1Y"  # plus observation period
gates:
  requireFreshEvidenceFor:
    - "prodRelease"
    - "keyRotation"
    - "policyChange"

OPA/Rego guard (release gate sketch)

package compliance.evidence

deny[msg] {
  input.action == "prodRelease"
  some cid
  cid := input.controlsImpacted[_]
  not evidence_current(cid)
  msg := sprintf("Release blocked: stale or missing evidence for control %s", [cid])
}

evidence_current(c) {
  some art
  art := input.evidence[c]
  time.now_ns() - time.parse_rfc3339_ns(art.generatedAt) < art.maxAgeNs
  art.hashAlg == "SHA-256"
  art.manifest.signed == true
}

Dashboards & KPIs (executive view)¶

Compliance score (per framework): % controls with fresh evidence (target ≥ 95%).
Evidence freshness: % artifacts within SLA (target 100% for critical controls).
Training completion: % workforce current (target 100%).
Incident KPIs: P1 notification SLA met, time-to-contain, time-to-close.
DSAR SLA: Avg. days to fulfill (target < 25 GDPR).
DR drills: Completed vs scheduled; pass rate and remediation status.

Auditor-Ready Artifacts¶

Framework packs: GDPR/HIPAA/SOC2 bundles with manifests, control mappings, and cross-refs.
Sampling support: Pre-filtered evidence sets (e.g., last 3 access reviews) + query scripts to reproduce.
Watermarking & access: Read-only, time-bound, watermarked exports; access logged in meta-audit.

Roles & RACI (excerpt)¶

DPO: Accountable for privacy evidence completeness and DPIA/ROPA accuracy.
Security Lead: Accountable for security control evidence and incident artifacts.
SRE Lead: Responsible for DR/backup evidence, availability SLAs.
Engineering Managers: Responsible for SDLC/SBOM/SAST/DAST evidence.
Compliance Ops: Coordinates auditor packs, tracks KPIs, runs quarterly reviews.

Done when¶

Evidence vault live with signed manifests; policy-as-code gates enforcing freshness.
Executive dashboard shows real-time compliance posture per framework.
One-click generation of auditor packs produces hash-verified bundles within minutes.

Cross-references: security-compliance.md (Control Framework, Incident Response) · data-residency-retention.md (Observability & Compliance Evidence) · pii-redaction-classification.md (Minimization & redaction evidence) · operations/observability.md (dashboards, metrics)

Privacy Incident Escalation & Classification¶

Goal: Classify and escalate privacy-impacting events fast and consistently, meeting legal timelines while preserving evidence integrity.

Incident Tiers¶

Tier	Definition	Typical Examples	Required Notification
P1 — Critical Breach	Confirmed unauthorized disclosure or loss of sensitive data (PII/PHI) with high risk to subjects	Exfiltration of PHI; compromised export bucket; keys leaked with access evidence	Regulator + affected tenants/subjects (jurisdictional timelines)
P2 — High, Potential Breach	Credible suspicion of exposure; scope not yet confirmed	Suspicious mass queries; stolen laptop with cached tokens; WAF bypass indicators	Tenant security contacts; prepare regulatory draft
P3 — Medium, Policy Violation	No exposure indicated, but controls bypassed or data mishandled	Over-privileged service account; export sent without manifest	Internal only (tenant notice if contractually required)
P4 — Low, Near-Miss	No exposure; anomaly or benign misconfiguration caught by guards	Failed attempted access; blocked egress by policy	Internal ops/security

Classification Criteria (score sketch)¶

Data sensitivity (0–3): Credential/PHI/PII class involved and volume.
Exposure likelihood (0–3): Confirmed access vs anomaly; presence of exfil paths.
Affected subjects (0–3): Count and jurisdictions (EU/HIPAA).
Regulatory impact (0–3): GDPR/HIPAA trigger likelihood, contractual SLAs.
Control state (0–2): Encryption at rest/in transit, keys compromised?

P1 if score ≥ 9 or confirmed exfiltration of Sensitive/PHI; P2 if 6–8; P3 if 3–5; else P4.

Escalation Paths¶

P1: DPO + Executive + Legal + Security on-call immediately; notify tenant exec contacts; regulator/subject notification workflow initiated.
P2: DPO + Security Lead; tenant security contact; prepare comms; expand forensics.
P3: Security team + Service owners; corrective actions; tenant notified per contract.
P4: Operational review by service owner + Security; ticket + learning recorded.

Response SLAs¶

Tier	Acknowledge	Contain	Classify	External Notice
P1	Immediate (≤ 15m)	≤ 2h	≤ 4h	Regulator per law (e.g., GDPR ≤ 72h); tenants ASAP
P2	≤ 1h	≤ 8h	≤ 24h	Tenant security contact within 24h if impact likely
P3	≤ 4h	≤ 2d	≤ 3d	Contractual, if applicable
P4	≤ 1d	≤ 5d	≤ 5d	None

Standard Workflow (all tiers)¶

Detect: SIEM alert / guard violation / anomaly detection.
Triage & Classify: Apply scoring; assign tier; open incident record.
Contain: Isolate tenant/region/component; revoke tokens; block egress; enable read-only where needed.
Eradicate & Recover: Patch/rotate; restore from trusted backups if required.
Investigate: Forensics with chain-of-custody; scope affected data/subjects.
Notify: Tenants, regulators, and subjects as required; approved templates only.
PIR (Post-Incident Review): Root cause, corrective/preventive actions, and ADRs for architectural changes.

Evidence & Records¶

Immutable incident ticket with: timeline, decisions, owners, artifacts (hashes), affected data classes, jurisdictions, notification proofs.
KMS/key ops, access logs, export manifests, guard decisions, and DSAR overlaps linked.
PIR outcomes: remediation tasks with owners & due dates.

Policy-as-Code (YAML sketch)¶

incidents:
  sla:
    p1: {ack: "PT15M", contain: "PT2H", classify: "PT4H", regulatorMax: "PT72H"}
    p2: {ack: "PT1H",  contain: "PT8H", classify: "P1D"}
    p3: {ack: "PT4H",  contain: "P2D",  classify: "P3D"}
    p4: {ack: "P1D",   contain: "P5D",  classify: "P5D"}
  classification:
    p1Threshold: 9
    rules:
      - if: "confirmedExfiltration && involves in ['Sensitive','PHI']"
        tier: "P1"
      - if: "score >= 9"
        tier: "P1"
      - if: "score >= 6"
        tier: "P2"
      - if: "score >= 3"
        tier: "P3"
      - else: "P4"
  notify:
    tenants: "on P1/P2 or contract"
    regulators: "GDPR/HIPAA triggers"

OPA/Rego Guard (escalation & notice)¶

package privacy.incident

tier("P1") { input.confirmedExfil && input.dataClass in {"Sensitive","PHI"} }
tier("P1") { input.score >= 9 }
tier("P2") { input.score >= 6; input.score < 9 }
tier("P3") { input.score >= 3; input.score < 6 }
tier("P4") { input.score < 3 }

deny[msg] {
  t := tier
  t == "P1"
  not input.notifications.regulator.prepared
  msg := "P1 requires regulator notification preparation"
}

breach_deadline_ns := time.parse_duration_ns("72h")

deny[msg] {
  t := tier
  t == "P1"
  elapsed := time.now_ns() - time.parse_rfc3339_ns(input.detectedAt)
  elapsed > breach_deadline_ns
  msg := "P1 breach beyond 72h window — escalate to exec/legal"
}

Communication Templates (high level)¶

P1 external: Plain-language summary, affected categories, mitigation steps, support contacts, reference ID.
P2 tenant: Suspected event, current scope, actions underway, next update timebox.
Internal updates: Cadence per tier (P1 hourly until containment).

Cross-references

security-compliance.md (§Incident Response & Forensics) · data-residency-retention.md (§Observability & Compliance Evidence) · pii-redaction-classification.md (§Classification for exposure assessment) · privacy-gdpr-hipaa-soc2.md (§GDPR Breach Notification)

Data Subject Rights Automation¶

Goal: Automate DSAR intake → verification → fulfillment with residency-aware exports, immutable evidence, and SLA guarantees.

Capabilities¶

Self-service portal: Tenant admins initiate and track DSARs (access, rectification note, erasure request, portability). Download exports when ready.
API workflows: Programmatic submission/fulfillment for tenant systems; idempotent tokens for retries; webhooks for status updates.
Identity verification: Pluggable verifiers (email link, KBA, document upload). Evidence recorded; timeout and retry windows.
Templates & manifests: Standardized responses (JSON/CSV/Parquet + signed manifest). Rectification handled via append-only corrective records.
SLA engine: Automatic deadline tracking (GDPR 30d, HIPAA 60d); reminders, escalations, and breach-of-SLA alerts.

Workflow (high level)¶

Intake: Tenant admin submits DSAR with subject identifiers and requested right(s). Duplicate detection merges repeats.
Verification: System requests proof-of-identity; on success, freezes clock start at verificationCompleteAt.
Scope & Hold Checks: Evaluate legal holds, retention status, residency constraints; compute safe query plan.
Fulfillment:
- Access/Portability: Generate export (NDJSON/Parquet/CSV) with classification-aware redaction and residency-pinned storage.
- Rectification: Capture corrective AuditRecord linked to originals (immutability preserved).
- Erasure: Queue for eligible deletion per retention policy; if not yet eligible, record deferred delete marker.
Delivery: Make artifacts available in the portal; optionally deliver to tenant-owned bucket; notify requester.
Closure: Record completion, SLA result, and signed manifest in evidence vault.

State machine¶

State	Entry Conditions	Exits
`Requested`	DSAR submitted, intake validated	`VerificationPending`, `Rejected` (invalid)
`VerificationPending`	Await PoI	`Verified`, `Rejected` (timeout)
`Verified`	PoI complete	`Processing`
`Processing`	Query/Export/Erasure planning	`Fulfilled`, `Deferred` (retention/hold), `Rejected`
`Deferred`	Legal hold or retention not met	`Fulfilled` (when eligible), `Closed` (tenant cancels)
`Fulfilled`	Artifacts ready or actions completed	`Closed`
`Rejected`	Policy violation or PoI fail	`Closed`
`Closed`	Terminal	—

API & payloads (sketch)¶

Create DSAR

POST /v1/privacy/dsar
Authorization: Bearer <tenant_admin_token>
Content-Type: application/json

{
  "tenantId": "t-123",
  "subject": { "email": "alice@example.com", "phoneE164": "+15551234567" },
  "rights": ["access","portability"],
  "jurisdiction": "GDPR",
  "evidencePolicyVersion": "v2025-01",
  "notify": { "email": "privacy-admin@tenant.com", "webhook": "https://tenant/hooks/dsar" }
}

Status

GET /v1/privacy/dsar/{id}

{ "id":"dsar_9Zr...", "state":"Processing", "slaDueAt":"2025-03-13T12:00:00Z", "links":[{"rel":"manifest","href":"..."}] }

Verification submit

POST /v1/privacy/dsar/{id}/verification
Content-Type: application/json

{ "method":"email_link", "evidence":"jwt_or_upload_ref" }

Download export (time-bound, signed)

GET /v1/privacy/dsar/{id}/artifacts/{artifactId}

Policy-as-code (SLA & roles, YAML sketch)¶

dsar:
  jurisdictions:
    GDPR: { slaDays: 30 }
    HIPAA: { slaDays: 60 }
  roles:
    submitters: ["TenantAdmin","DPODelegate"]
    viewers: ["TenantAdmin","DPODelegate","Auditor(ReadOnly)"]
  verification:
    methods: ["email_link","kba","document_upload"]
    timeout: "P7D"
  export:
    formats: ["NDJSON","Parquet","CSV"]
    residency: "enforce"   # no cross-region by default
  erasure:
    obeyRetention: true
    obeyLegalHolds: true

OPA/Rego guards (excerpt)¶

package privacy.dsar

deny[msg] {
  input.action == "export"
  input.tenant.euOnly == true
  input.destination.region != "EU"
  msg := "Residency policy forbids cross-region DSAR export"
}

deny[msg] {
  input.action == "erasure"
  input.record.legalHold == true
  msg := "Erasure blocked by active legal hold"
}

deny[msg] {
  input.action == "close"
  input.sla.overdue == true
  not input.justificationProvided
  msg := "Cannot close overdue DSAR without justification"
}

Export manifest (signed)¶

{
  "dsarId": "dsar_9Zr...",
  "tenantId": "t-123",
  "jurisdiction": "GDPR",
  "policyBundle": "policy-atp-privacy-v1",
  "classificationPolicy": "policy-atp-v1",
  "redactionProfile": "auditor-default",
  "generatedAt": "2025-02-18T10:22:03Z",
  "artifacts": [
    {"name":"events.ndjson","sha256":"...","rows":256_103,"region":"EU"},
    {"name":"events.parquet","sha256":"...","rows":256_103,"region":"EU"}
  ],
  "signatures": [{"alg":"Ed25519","keyId":"k-ops-01","sig":"..."}]
}

Sequence (Mermaid)¶

sequenceDiagram
  participant Admin as Tenant Admin
  participant API as Privacy API
  participant Verify as Verifier
  participant Engine as DSAR Engine
  participant Export as Export Svc
  participant Vault as Evidence Vault

  Admin->>API: Create DSAR (access, portability)
  API->>Verify: Start PoI
  Verify-->>Admin: Verification request (email/KBA)
  Admin->>Verify: Provide evidence
  Verify-->>API: Verification success
  API->>Engine: Plan query (residency, holds)
  Engine->>Export: Generate redacted export (EU region)
  Export-->>Vault: Store artifacts + manifest (signed)
  Export-->>API: Artifact references
  API-->>Admin: Ready + download links

Hold "Alt" / "Option" to enable pan & zoom

Observability & KPIs¶

Metrics: dsar_created_total, dsar_verified_total, dsar_sla_breaches_total, dsar_export_bytes_total, dsar_avg_time_to_fulfill.
Logs: State transitions with reason, verification outcomes, denial reasons (OPA), artifact hashes.
Dashboards: Aging by state, SLA burn-down, residency violations (should be zero), hold-blocked erasures.

Security & abuse mitigation¶

Rate limit DSAR endpoints; CAPTCHA for portal submissions.
Encrypt artifacts at rest (per-tenant keys); signed URLs with short TTL.
Strict scope checks: only tenant admins/DP officers can view/download.
All access to DSAR artifacts logged in meta-audit (who/when/what).

Acceptance criteria¶

Portal + API can create, verify, fulfill, and close DSARs with evidence and manifests.
SLA engine raises alerts before breach; escalations logged.
Exports are residency-compliant and carry signed manifests referencing policy versions.
Erasure requests respect retention and legal holds; deferred items tracked to completion.
End-to-end traces visible from intake to delivery; KPIs green for a sample tenant.

Cross-references

guides/export-and-ediscovery.md (export mechanics) · data-residency-retention.md (residency, legal holds, deletion) · pii-redaction-classification.md (classification & redaction) · security-compliance.md (incident response, policy guards)

Use: Copy, fill, and version in the privacy repo. Link each DPIA to the relevant ADRs and processing registers (ROPA).

dpia:
  id: DPIA-ATP-YYYY-NN
  version: 1
  preparedBy: "<name@connectsoft.ai>"
  reviewedByDPO: false
  dates:
    createdAt: "2025-01-15T10:00:00Z"
    lastReviewedAt: null
  processingDescription:
    purpose: "Platform-wide audit processing for accountability and security for <tenant class>."
    dataCategories:
      - "Personal (emails, IPs)"
      - "PHI (where applicable)"
    dataSubjects: ["Tenant end-users", "Tenant admins", "Operators (meta-audit)"]
    recipients: ["Tenant admins", "Auditors (read-only)"]
    retention: "Default 7y or tenant-configured within bounds"
    securityMeasuresRefs:
      - "security-compliance.md"
      - "pii-redaction-classification.md"
      - "data-residency-retention.md"
  necessityProportionality:
    justification: "Audit logs are necessary for security, fraud detection, and legal accountability."
    alternativesConsidered: ["Reduced scope logging", "Anonymized-only logs (insufficient for forensic needs)"]
    dataMinimization: "Classification + default redaction; credentials dropped at write."
  riskAssessment:
    methodology: "Likelihood x Impact (1–5)"
    threats:
      - name: "Unauthorized access"
        likelihood: 2
        impact: 5
        mitigations: ["RBAC/ABAC", "mTLS", "SIEM detection"]
      - name: "Cross-border transfer"
        likelihood: 1
        impact: 4
        mitigations: ["Residency enforcement", "SCCs"]
  mitigationMeasures:
    technical: ["Per-tenant encryption", "Hash chains", "OPA-based guards"]
    organizational: ["Access reviews", "Privacy training", "Vendor DPAs/BAAs"]
  dpoConsultation:
    consulted: true
    notes: "DPO recommends additional logging redaction in Support tooling."
  residualRisk:
    level: "Low"
    justification: "Controls effective; evidence collected continuously."
  approvals:
    approver: "Chief Privacy Officer"
    approvedAt: "2025-01-20T14:32:00Z"
    supervisoryAuthorityConsulted: false

Risk matrix (example)

Likelihood	Impact	Score	Action
1–2	1–2	≤ 4	Accept, monitor
2–3	3–4	6–9	Mitigate + track
4–5	4–5	≥ 16	Escalate; consult DPO; consider SA consultation

Appendix F — HIPAA BAA Key Clauses¶

Required clauses (summary)

Permitted Uses/Disclosures: ATP processes PHI solely to provide audit services to the Covered Entity/Business Associate; prohibits secondary use.
Safeguards: Administrative, physical, and technical safeguards consistent with the HIPAA Security Rule; evidence available upon request.
Subcontractors: ATP ensures subcontractors with PHI access are bound by equivalent BAAs and safeguards.
Individual Rights: ATP supports Covered Entity obligations for access and amendment by supplying necessary audit artifact exports.
Breach Notification: ATP notifies the Covered Entity without unreasonable delay (e.g., ≤ 5 business days) upon discovery of a breach involving PHI.
Access to Records: ATP permits HHS and the Covered Entity to audit relevant policies, procedures, and records related to PHI safeguards.
Termination: On termination, ATP returns or destroys PHI if feasible; if not feasible, extends protections and limits further use.

Sample wording (excerpt)

Business Associate shall not use or disclose PHI other than as permitted or required by this Agreement or as Required by Law, and shall use appropriate safeguards and comply with Subpart C of 45 CFR Part 164 with respect to electronic PHI to prevent use or disclosure other than as provided for by this Agreement.

Evidence pointers

BAA file version, signed date, covered systems list, subprocessor register link, incident contact details.

Appendix G — SOC 2 Testing Procedures (Examples)¶

Control	Test Procedure	Sample Size	Frequency	Evidence
MFA enforcement	Review admin login logs; verify MFA challenges for privileged roles	25 logins	Monthly	SIEM extracts, IdP report
Encryption at-rest	Inspect storage configs; confirm per-tenant keys + rotation policy	All tenants	Quarterly	KMS key map, rotation logs
Access reviews	Validate quarterly attestation from owners; verify revocations applied	4 quarters	Per period	Review tickets, IAM diffs
Change management	Sample ADRs/PRs; verify approvals, CI checks, and rollback plan	20 changes	Monthly	ADR IDs, PR links, pipeline logs
Incident response	Inspect P1/P2 incidents; verify timelines, notifications, PIR	All P1/P2	Per incident	Incident record, PIR, artifacts
Backup & restore	Perform file-level restore drill; verify integrity and residency	3 tenants	Quarterly	Restore logs, checksums
Vendor reviews	Confirm annual review of critical vendors; SOC 2/ISO reports on file	All critical	Annual	Vendor risk assessments

Notes

Sampling uses auditor-defined randomization.
Failures produce CAPAs with owners and due dates.
Keep a control test calendar aligned to observation period.

Appendix H — Compliance Metrics & KPIs¶

Definition & collection

Metrics sourced from SIEM, policy engines (OPA), DSAR engine, CI/CD, and KMS.
All KPIs include owner, query, and dashboard link. Targets set per quarter.

KPI	Target	Measurement	Reporting
DSAR response time	< 25 days (GDPR)	Avg. days from verification to fulfillment	Monthly
Security training completion	100%	% workforce completed annual training	Quarterly
Policy compliance score	≥ 95%	% automated checks passing (OPA/CI)	Weekly
Incident resolution time	P1 < 4h, P2 < 24h	Detection → remediation elapsed	Monthly
Audit findings closure	100% ≤ 90 days	% findings closed within SLA	Quarterly
Encryption coverage	100%	% data encrypted at rest/in transit	Continuous

Example queries (sketch)

DSAR SLA (SQL)

SELECT AVG(DATEDIFF(day, verificationCompleteAt, fulfilledAt)) AS avg_days
FROM dsar_requests
WHERE jurisdiction='GDPR' AND period='2025-Q1';

* Policy compliance (OPA bundle status, PromQL)

sum(opa_policy_checks_passed) / sum(opa_policy_checks_total)

Dashboards

Privacy Overview: DSAR pipeline, SLA burn-down, open DPIAs, overdue actions.
Security Controls: MFA coverage, key rotations, encryption validation over time.
Audit Readiness: Evidence freshness heatmap, control test schedule adherence.

Alerts (examples)

DSAR due in ≤ 5 days and state != Fulfilled → page DPO.
OPA policy compliance < 95% for 2 consecutive checks → open P2.
Key rotation overdue by > 7 days → escalate to Platform Security.

Privacy (GDPR/HIPAA/SOC2) - Audit Trail Platform (ATP)¶

Purpose & Scope¶

Privacy-by-Design Principles¶

Design patterns (how this shows up in code & ops)¶

Evidence & checks (auditor-ready)¶

GDPR Compliance Overview¶

Implementation anchors (how ATP meets GDPR)¶

Evidence artifacts (auditor-ready)¶

GDPR: Lawfulness, Fairness, Transparency¶

Lawfulness¶

Fairness¶

Transparency¶

Evidence (auditor-ready)¶

Validation & monitoring¶

GDPR: Data Subject Rights Implementation¶

Right of Access (Art. 15)¶

Right to Rectification (Art. 16)¶

Right to Erasure (Art. 17)¶

Right to Data Portability (Art. 20)¶

Right to Object (Art. 21)¶

Shared controls (applies to all rights)¶

Metrics & SLAs¶

GDPR: Storage Limitation & Retention (Art. 5.1.e)¶

Retention policy¶

Automated purge workflows¶

Legal holds & overrides¶

Verification & reporting¶

Evidence (auditor-ready)¶

GDPR: Data Residency & Cross-Border Transfers¶

Residency enforcement (design-time & run-time)¶

Cross-border safeguards (when transfer is necessary)¶

Failover constraints (resiliency with residency)¶

Evidence (auditor-ready)¶

GDPR: Security of Processing (Art. 32)¶

Encryption¶

Access controls¶

Integrity (tamper-evidence)¶

Confidentiality (minimization & redaction)¶

Operational safeguards¶

Evidence (auditor-ready)¶

Metrics & SLOs¶

GDPR: Breach Notification (Art. 33–34)¶

Detection¶

Triage & Assessment¶

Notification workflow¶

Evidence & records¶

Metrics & SLAs¶

Templates (excerpts)¶

HIPAA Compliance Overview¶

Scope & roles¶

Applicability & obligations¶

Key HIPAA rules (how ATP aligns)¶

Processing boundaries¶

Evidence (auditor-ready)¶

HIPAA: Administrative Safeguards¶

Security Management Process (45 CFR §164.308(a)(1))¶

Assigned Security Responsibility (45 CFR §164.308(a)(2))¶

Workforce Security (45 CFR §164.308(a)(3))¶

Information Access Management (45 CFR §164.308(a)(4))¶

Security Awareness and Training (45 CFR §164.308(a)(5))¶

Security Incident Procedures (45 CFR §164.308(a)(6))¶

Contingency Plan (45 CFR §164.308(a)(7))¶

Business Associate Contracts (45 CFR §164.308(b)(1))¶

Metrics & SLAs (program health)¶

HIPAA: Physical Safeguards¶

Facility Access Controls (45 CFR §164.310(a))¶

Workstation Use/Security (45 CFR §164.310(b)-©)¶

Device and Media Controls (45 CFR §164.310(d))¶

Metrics & SLAs¶

Quick policy excerpt (YAML)¶

HIPAA: Technical Safeguards¶

Access Control (45 CFR §164.312(a))¶

Audit Controls (45 CFR §164.312(b))¶

Integrity (45 CFR §164.312©(1))¶

Person or Entity Authentication (45 CFR §164.312(d))¶

Transmission Security (45 CFR §164.312(e)(1))¶

Artifacts (auditor-ready)¶

Metrics & SLAs¶

SOC 2 Compliance Overview¶

Framework & scope¶