Data Security & Compliance Playbook

Map sensitive data, assign control owners, test access and recovery, and prepare evidence for qualified security, privacy, legal, and assurance review.

trigger="A product handles sensitive data, changes its processing, or needs a scoped security and compliance evidence review." owner="The security program owner, partnered with the engineering owner of the in-scope service." participants={["Data owner", "Privacy and qualified legal reviewers", "Identity and platform owners", "Incident commander", "Vendor owner", "Assurance or audit lead"]} prerequisites={[ "An agreed system boundary, data-flow inventory, relevant contracts, and accountable business owners.", "Approved access to configuration and sanitized evidence, plus a safe environment for control tests.", "Named escalation contacts, recovery access, and a process for approving changes and exceptions." ]} outputs={[ "A data map, applicability decision record, and risk-ranked control backlog.", "A control-to-evidence matrix with test results, exceptions, and review dates.", "Tested access, deletion, containment, and recovery procedures with accountable operators." ]} doneWhen={[ "Qualified reviewers resolve applicability and record any remaining legal or assurance questions.", "Control owners demonstrate both permitted and denied behavior in the agreed system boundary.", "Incident and restore exercises expose no unowned critical recovery dependency.", "Evidence is reproducible, access-controlled, and explicit about gaps rather than presented as a compliance certificate." ]} />

Security evidence is not a compliance determination

Use this playbook to organize engineering work and the evidence required for review. It does not certify SOC 2, establish GDPR or HIPAA compliance, or replace qualified legal and assurance advice. A secure configuration can support an obligation without proving that every organizational, contractual, and legal requirement has been met.

Do not start with a list of tools or an industry breach-cost statistic. Start with the harm that could follow from unauthorized disclosure, alteration, loss, or unavailability of this system's data. Identify who can accept the residual risk and who is authorized to determine applicability.

Choose a bounded service or data flow for the first review. Expanding to the whole organization before establishing ownership often produces a large checklist with weak evidence.

1. Record scope and applicability before selecting controls

The security owner documents environments, services, data categories, users, vendors, geographic processing locations, and exclusions. The legal and privacy reviewers assess relevant jurisdictions, business relationships, contracts, and organizational roles.

| Topic | What the reviewer determines | Engineering contribution | | --- | --- | --- | | SOC 2 | Examination scope, criteria, system description, and evidence expectations | Control operation and traceable records | | GDPR | Applicable processing and controller or processor responsibilities | Data flows, access, retention, and request handling | | HIPAA | Covered-entity or business-associate role and relevant obligations | Data handling, system safeguards, and vendor boundaries | | Customer commitments | Actual security, availability, retention, and notification terms | Feasibility, monitoring, and tested procedures |

AICPA describes SOC services as assurance offerings. SOC 2 is not a law or a universal prerequisite for every enterprise transaction. Agree the examination and evidence needs with the assurance team instead of promising that a tool purchase satisfies them.

HHS states that HIPAA applies to covered entities and business associates. Handling health-related information alone does not settle that classification. The qualified reviewer must resolve the role and any required business-associate arrangements; other laws may still apply when HIPAA does not.

GDPR Article 3 addresses establishment in the Union and specified offering or monitoring activities involving people in the Union. “Any data about an EU resident” is not a sufficient applicability test.

Gate: unresolved applicability is an open decision with an owner. It must not become an unsupported “compliant” label in product documentation or a customer response.

2. Map data copies and trust boundaries

The data owner inventories collection, purpose, sensitivity, access, processing, sharing, retention, and disposal. Include replicas, search indexes, analytics, exports, support tools, logs, backups, and third-party processors. Record identifiers that connect copies without creating a new unprotected identity database.

"type": "svg-architecture", "title": "Review the complete sensitive-data path", "nodes": [ ], "links": [ ], "caption": "This is a review map, not a security guarantee. Each boundary needs an owner, permitted use, denial tests, and an evidence source." }} />

For each boundary, ask what an attacker or mistaken operator could read, modify, impersonate, or make unavailable. Include tenant isolation, administrative access, compromised vendor credentials, bulk export, and recovery access. Prioritize by plausible harm and exposure, not a generic severity label alone.

Classify the data using a scheme the organization can operate. A category is useful only if it leads to specific handling rules. For example, logs containing customer identifiers need a defined access and retention policy even if the application database already has encryption enabled.

3. Convert risks into testable control statements

A control statement should identify the protected activity, enforcement point, owner, exception path, and test. “We use zero trust” is not a testable statement. “A support user cannot export another tenant's records, including through a background job” is.

| Control area | Positive test | Negative or failure test | | --- | --- | --- | | Object authorization | Allowed user accesses the intended record | Different tenant, revoked role, or altered object ID is denied | | Privileged access | Approved operator completes the task | Expired approval or disabled identity cannot continue | | Data export | Approved job produces only scoped data | Export cannot bypass source permissions or retention | | Secret retrieval | Authorized workload obtains its required secret | Wrong workload or environment is denied | | Audit evidence | Sensitive action creates a useful event | Missing or failed audit delivery is detectable | | Recovery | Approved operator restores usable data | Restore does not silently reactivate deleted or unauthorized data |

Document compensating controls and residual risk where a required behavior is not yet implemented. An infrastructure declaration proves intended configuration; inspect deployed state and behavior to show that the control operates.

Evidence should include environment, version, timestamp, test identity, expected outcome, observed outcome, and reviewer. Use synthetic data where possible. Redact secrets and sensitive records before attaching evidence to a broadly accessible ticket.

4. Engineer identity, secrets, and encryption with recovery

The identity owner removes unnecessary privilege and shared human accounts, establishes approved authentication requirements, and tests joiner, role-change, and leaver flows. Include active sessions, API tokens, cached permissions, and background jobs when testing revocation.

Select token lifetimes, session rules, authentication methods, and rotation schedules from the threat model, supported platform behavior, and applicable obligations. This guide does not prescribe one duration for every API key or claim that a short-lived access token is low risk.

Prefer managed workload identity where appropriate, with scoped trust and authorization. Temporary credentials still require secure issuance, policy, logging, and recovery. Document any long-lived credential exception and its replacement plan.

The platform owner defines supported encryption protocols, key custody, access separation, backup encryption, and key-recovery requirements. Encryption at rest does not prevent an authorized but compromised application from reading plaintext. Test key unavailability and access revocation without destroying the only means of restoring data.

Before tightening access, confirm an independently protected emergency-access path. Exercise it under approval and audit it afterward. A control rollout that locks out every responder can turn a manageable incident into a prolonged outage.

5. Treat erasure and retention as a controlled workflow

GDPR Article 17 provides erasure grounds and exceptions; it is not an unconditional command to delete every record or backup on request. Qualified privacy and legal reviewers determine the applicable action and timing. Use the regulation itself when resolving those questions.

The following is an engineering workflow proposal, subject to that determination:

1. The request owner verifies the requester and resolves the exact subject and scope without exposing another person's data.
2. The privacy owner decides the action, exceptions, and response requirements.
3. The data owner builds a manifest of affected stores, derived copies, recipients, and retained exceptions.
4. Operators execute approved actions with per-target status, retries, and failure escalation.
5. The reviewer verifies results using controlled test records and documents outstanding copies or constraints.
6. The recovery owner tests that restoring an older backup cannot silently reintroduce data that should remain unavailable.

Do not claim a live-row deletion also removed exports, logs, or immutable backups. Document the approved backup lifecycle, access restrictions, and reapplication of deletion decisions during restore. Retention and legal-hold conflicts go to the designated reviewer, not an automatic cleanup job.

Keep sufficient request evidence without unnecessarily retaining the data the request was meant to remove. Partial completion remains open until the owner resolves each failed target or approved exception.

6. Rehearse incident containment and notification decisions

NIST SP 800-61 Revision 3 places incident response within cybersecurity risk management. Use it to structure preparation, detection, response, and recovery responsibilities, rather than imposing a universal first-thirty-minutes script.

The incident commander assesses the observed threat and authorizes containment appropriate to its urgency. Credential revocation may be urgent, but it is not always operationally harmless. Identify dependent services, replacement credentials, recovery access, and evidence that must be preserved. Where active misuse requires immediate revocation, record and manage the resulting service impact; do not wait for a perfect dependency inventory.

"type": "flow", "title": "Contain a suspected credential compromise", "steps": [ ], "caption": "Containment order depends on urgency. Preserve safe responder access and evidence, and do not restore a compromised credential merely to restore availability." }} />

Maintain a restricted incident timeline with detection, awareness, decisions, actions, affected systems, evidence locations, and uncertainty. Involve legal, privacy, and contractual notification owners early. Technical investigation and notification assessment run in parallel.

Under GDPR Article 33, a controller notifies the competent authority without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to pose risk to people's rights and freedoms. Processors notify controllers without undue delay. Article 34 separately addresses high-risk communication to affected people, with exceptions. These are not erasure deadlines. GDPR Articles 33 and 34.

7. Test restoration and supply-chain controls

The service owner rehearses recovery in an isolated environment with approved data handling. Verify application behavior, identity policies, keys, dependencies, integrity, and the handling of deletion decisions. A successful backup job is not a successful restore.

For application changes, the engineering owner defines dependency review, security testing, artifact provenance, and patch response based on exposure and exploitability. Do not automatically merge every patch because its version number appears small. Preserve tests and a recovery plan for the update.

Test what happens when logging, identity, a secrets service, or a critical vendor is unavailable. Define which operations stop safely, which continue with bounded risk, and who may invoke an exception. Never let a monitoring outage silently disable authorization.

If a new control breaks legitimate work, use the approved rollback or compensating-control path. Do not broadly reopen access without recording scope, expiry, approver, and follow-up. Incident containment changes may require a new safe configuration rather than restoration of the old one.

8. Maintain a reusable control and evidence record

System boundary, environment, and control ID:
Business risk and affected data:
Applicability decision owner and reference:
Control statement and enforcement point:
Implementation owner and deployed version:
Permitted, denied, failure, and recovery test cases:
Evidence location, capture date, and access restrictions:
Observed result and known coverage gaps:
Exception, compensating control, approver, and expiry:
Incident or rollback procedure:
Next review trigger and accountable owner:

Automated evidence collection can reduce manual effort, but the assurance owner must verify scope, completeness, freshness, and access. A dashboard marked green does not resolve an untested control or a vendor contract outside its coverage.

9. Review third-party evidence without inheriting its conclusion

For each service provider, record the exact product, edition, region, processing purpose, data categories, integration path, subprocessors where relevant, and internal owner. Obtain current contractual and assurance material through the approved procurement or security process. A provider's certification or report covers a stated system and period; it does not automatically cover the way your application is configured or used.

Map provider controls to your own responsibilities. The provider may protect its infrastructure while your team remains responsible for tenant authorization, retention configuration, encryption-key choices, identity federation, exported data, application logs and incident decisions. Record complementary user-entity controls and test the ones the service depends on.

Review operational dependencies: support access, regional failover, backup or export capability, key ownership, audit events, deletion APIs, rate limits, service termination and data return. Exercise at least one exit or recovery path with representative non-production data. A contract clause promising export is not evidence that identifiers, permissions and deletion state can be reconstructed.

Track assurance expiry and material service changes. New features, regions, subprocessors or identity modes may alter the boundary. Reopen the review when the data use or risk changes, not only when a document reaches its annual renewal date.

If evidence is unavailable, record the gap and decide whether a narrower use, compensating control, delayed launch or alternative provider is appropriate. Do not invent assurance from marketing language or treat a lack of reported incidents as proof of safety.

10. Conduct an evidence retrieval and control-failure drill

Select one consequential control, such as tenant-scoped export or privileged support access. Give an operator the current alert, system identity and ordinary runbook. Ask them to determine the intended control, retrieve current implementation evidence, reproduce a permitted and denied test in an authorized environment, and explain the recovery path if enforcement fails.

The drill should expose whether evidence is current, comprehensible and accessible to the right people. If the only proof is a screenshot from a former employee, a production query nobody can safely repeat, or a vendor console visible to one person, the assurance process is fragile.

Inject one failure, such as expired emergency access, missing audit delivery, an unavailable policy service or a restored backup containing a deleted test record. The operator should contain the risk without broadening access, preserve evidence, invoke the correct owner and document the unresolved state. Record time to useful evidence separately from time to final repair.

After the drill, update the control statement, runbook, evidence source and ownership. Remove temporary access and synthetic data. Any exception created during recovery receives a scope, approver, compensating control and expiry. The exercise is complete only when a second reviewer can follow the record and reach the same bounded conclusion.

Keep the remediation backlog decision-ready

Each gap should state the affected control, plausible consequence, current exposure, temporary protection, implementation owner, validation method and decision date. Separate confirmed failures from missing evidence. Both matter, but they require different next actions.

Prioritize items with the relevant risk owners. A security owner may need urgent containment, a privacy owner may need an applicability decision, and a service owner may need to protect availability during remediation. Avoid collapsing these judgments into one unsupported numeric score.

Close an item only when the required behavior is deployed and the agreed positive, negative, failure and recovery evidence passes. A merged change or updated policy document is not sufficient. If the organization accepts the residual risk, record the accountable authority, scope, conditions and next review trigger instead of marking the gap fixed.

Review dependencies between items. Tightening one identity policy can break backup recovery; shortening retention can remove incident evidence; rotating a key can strand encrypted backups. Sequence changes so that one control improvement does not silently invalidate another required capability.

11. Close with explicit decisions and remaining gaps

"The system boundary, data copies, third parties, and accountable owners are recorded.", "Qualified reviewers have resolved applicability or retained specific open decisions.", "Access controls pass cross-tenant, revoked-identity, and privileged-operation tests.", "Secrets and key changes preserve safe recovery access and have dependency-aware procedures.", "Deletion evidence covers derived data and approved backup restoration behavior.", "Incident containment and notification responsibilities have been exercised together.", "Control evidence includes negative and failure tests, not only configuration screenshots.", "Exceptions have risk owners, compensating controls, and review or expiry conditions." ]} />

The handoff is a scoped evidence pack and an owned remediation backlog. No breach-cost, detection-time, or enterprise-adoption statistic is needed to claim value, and no unverified benchmark is presented as an organizational result. Security, legal, privacy, and assurance sign-off remain separate approval gates.