View a markdown version of this page

DSOPS02-BP01 Baseline your compliance requirements - Digital Sovereignty Lens
Implementation guidanceResources

DSOPS02-BP01 Baseline your compliance requirements

Compliance requirements accumulate from multiple sources: cybersecurity directives, data privacy legislation, industry regulations, and internal policies. These requirements can overlap or diverge, whether you operate in one jurisdiction or many. A compliance baseline maps each requirement to specific technical controls so that teams can implement, test, and audit them consistently.

Desired outcome:

  • Your organization maintains a compliance catalog that maps regulatory requirements to technical controls, validation criteria, and audit evidence.

  • The catalog covers organizational controls that apply across jurisdictions and workload-specific controls where regulations differ.

  • Teams use the catalog to identify gaps, resolve divergences between overlapping frameworks, and demonstrate compliance posture to auditors on demand.

Common anti-patterns:

  • Making decisions based on informal understanding rather than documented requirements.

  • Applying the same compliance controls across workloads without considering specific regulatory requirements.

  • Only identifying requirements after a compliance issue or audit finding occurs.

  • Creating compliance baselines once and rarely updating them as regulations evolve.

Benefits of establishing this best practice:

  • Risk reduction through proactive identification of compliance gaps before they appear in audits or incidents.

  • Cost optimization by implementing controls proportionate to regulatory requirements, avoiding over-engineering.

  • Improved audit readiness with documented traceability from regulatory requirements to technical controls and validation criteria.

  • Faster onboarding of new workloads or jurisdictions by reusing an established compliance baseline.

Level of risk exposed if this best practice is not established: High

Implementation guidance

Compliance requirements arrive from many sources at once and at different levels of specificity. A compliance catalog provides traceability by creating a single, structured artifact that connects each regulatory obligation to specific technical controls, validation criteria, and audit evidence. Teams implement controls consistently because the mapping is explicit, and auditors can verify coverage directly from the catalog rather than through manual investigation.

Many regulatory frameworks overlap in their requirements. The General Data Protection Regulation (GDPR), the Network and Information Systems Directive (NIS2), and Payment Card Industry Data Security Standard (PCI-DSS) may all require encryption at rest, or access logging, but express these requirements in different terminology and at different levels of specificity. A well-structured catalog maps multiple framework requirements to shared control objectives, so that a single implementation satisfies multiple regulatory obligations without duplicating effort. This multi-framework convergence reduces the total number of controls to implement and maintain while providing auditors with clear traceability from a requirement to its shared implementation.

The catalog benefits from separating cloud service provider (CSP) agnostic control objectives from CSP-specific implementations. A control objective such as "restrict data processing to approved jurisdictions" is universal and maps to multiple standards. The CSP-specific implementation (for example, applying a Region deny Service Control Policy through AWS Control Tower) is how that objective is technically applied on AWS. This separation enables organizations to maintain portability of their compliance logic while documenting precisely how each objective is met in their chosen environment.

The catalog tiers controls by applicability into organizational, jurisdiction-specific, and workload-specific levels. This tiering enables reuse because new workloads inherit applicable organizational and jurisdiction-specific controls automatically, requiring only workload-specific controls to be defined.

Implementation steps

  1. Develop a compliance catalog: Create a compliance catalog (also known as a compliance workbook) that maps regulatory requirements to specific technical controls, validation criteria, and audit evidence. Structure the catalog using a control hierarchy organized by domains and categories. The AWS Control Catalog uses one such hierarchy, which you can observe in the AWS Management Console when viewing control details such as CT.S3.PR.11 - Require an Amazon S3 bucket to have versioning enabled. The Cloud Security Alliance Cloud Controls Matrix (CCM v4.1) offers an alternative meta-framework that maps control specifications to multiple standards. These are two examples of how to structure a compliance workbook. Other approaches exist, and the right structure depends on your organization's specific requirements. Collaborate with your compliance teams to define the structure that fits your needs.

  2. Define controls: Whichever structure you choose, for a compliance catalog to be useful, consider the following.

    • List a set of fully defined non-overlapping controls. Controls are usually identified by an internally recognized unique id. For example, OPS-001, DRC-002.

    • Organize controls logically by CSP-agnostic domains, functions, and control objectives. (See tables in Steps 5 and 6 below).

    • Include CSP-agnostic implementation guidance for each control. If required, also include jurisdiction-specific implementation guidelines.

    • Map control objectives to standards.

    • List CSP-specific technical controls (for example, AWS Control Tower Controls) for each control id. Also list procedural controls when a control objective can't be met through technical measures only.

    • State a control's applicability: the class of workloads, data classification levels, or jurisdictions it applies to.

    • State enablement tier. Whether the control is applied at an organizational level, per jurisdiction or is workload-specific.

    • Show how the CSP-specific technical controls will be verified (unit testing, integration testing) and monitored (metrics) at runtime.

    • List what data or documentation needs to be collected as evidence in support of audits.

  3. Assign ownership: Assign ownership of sections of the catalog to teams and roles best positioned to maintain them. Security and compliance subject matter experts (SMEs) typically define CSP-agnostic control domains, control objectives, implementation guidelines, and standards mappings. DevSecOps and engineering teams list CSP-specific controls, validation criteria, and compliance metrics. Compliance SMEs supporting audits define the evidence requirements.

  4. Document organizational-level controls: The following example illustrates a fully documented organization-level control applicable to workloads across all jurisdictions. The control id OPS-001 is an internal id and is unique to your organization.

    Note: The control mapping shown in the following table is only for illustration purposes. It isn't accurate and may not be up to date with the latest AWS Documentation. Your compliance workbook might be structured differently.

    Control Id OPS-001
    1 Category Operational Boundary
    2 Control Objective Restrict operations to approved jurisdictions, ensuring data processing occurs only within jurisdictional boundaries.
    3 Tier Organizational Default
    4 Implementation Guidance Implement policy-based guardrails at the organization level to limit storage and processing to within approved jurisdictions only. Exempt global services (identity, DNS, CDN, billing) that have no regional boundary. Maintain an exemption register for principals and actions that must operate cross-region.
    5 Standards Mapping CCCS Medium Cloud Control (May 2019) [AC-4, SC-7, SC-7(5)], CIS Controls v8.0 [4.2, 4.1, 12.2] NIST SP 800-53 Rev 5 [SC-7(5) SC-7 AC-4], NIST CSF v1.1 [PR.AC-5 PR.PT-3], NIST SP 800-171 Rev 2 [3.13.1 3.1.3], PCI DSS v4.0 [1.2.1,1.2.2], PCI DSS v3.2.1 [1.1, 1.1.1 , 1.2.1], FedRAMP Rev 4 [SC-7, SC-7 (5), AC-4], CIS AWS Benchmark v1.4 [5.4]
    6 Implemented By CT.MULTISERVICE.PV.1: Deny access to AWS services based on the requested AWS Region for an organizational unit
    7 Services Covered All AWS Services
    8 Example Validation Criteria Attempt resource creation in non-allowed jurisdictions, expect access denied. Query resource inventory for assets outside allowed jurisdictions, expect zero. Validate global service exemptions function correctly. Test exempted principal access in non-allowed jurisdictions, expect success.
    9 Example Monitoring Logged CloudTrail Access Denied events. Exempted principal usage frequency.
    10 Example Evidences Policy-as-Code documents. Config aggregator showing zero resources beyond approved jurisdictions. List of exempted principal and actions with justifications. AWS Region selection rationale document. Denied-request log samples.

  5. Document jurisdiction-specific and workload-specific controls: Document jurisdiction-specific and workload-specific cybersecurity, data privacy, and industry-specific regulatory requirements. The following is an example of a workload-specific control. Backup requirements may not be applicable to a workload if it is stateless (for example a tax calculation microservice). The control id DRC-002 is an internal id and is unique to your organization.

    Note: The control mapping shown in the following table is only for illustration purposes. It isn't accurate and may not be up to date with the latest AWS Documentation. Your compliance workbook might be structured differently.

    Control Id DRC-002
    1 Category Data Recoverability: Automated Backup & Snapshots
    2 Control Objective Verify automated backups are enabled with defined retention periods for all stateful services
    3 Tier Workload-Specific
    4 Implementation Guidance Configure automated daily backups with minimum retention aligned to RPO. Define retention per data classification tier. Enable cluster-level rewind (backtracking) where supported for fast recovery without full snapshot restore.
    5 Standards Mapping NIST CP-9/CP-10, ISO A.8.13, GDPR Art.32(1)(c), DORA Art.11, SOC2 A1.2/A1.3, PCI DSS 10.5.1, CSA CCM BCR-09/BCR-11
    6 Implemented By [CT.RDS.PR.8] Require an Amazon RDS database instance to have automatic backups configured. [CT.RDS.PR.6] Require an Amazon RDS database cluster to have backtracking configured. [CT.ELASTICACHE.PR.1] Require an Amazon ElastiCache (Redis OSS) cluster to have automatic backups activated. [CT.S3.PR.6] Require an Amazon S3 bucket to have lifecycle policies configured
    7 Services Covered RDS, Aurora, ElastiCache, S3 [Add more services as and when they are approved for use]
    8 Example Validation Criteria CT.RDS.PR.8 pass, fail conditions. CT.RDS.PR.6 pass, fail conditions. CT.ELASTICACHE.PR.1 pass, fail conditions. CT.S3.PR.6 pass, fail conditions.
    9 Example Monitoring Config rules for backup retention compliance – [SH.S3.13] S3 buckets should have lifecycle policies configured, [CONFIG.RDS.DT.1] Checks if an Amazon Aurora MySQL cluster has backtracking enabled, [SH.RDS.11] RDS instances should have automatic backups enabled – CloudTrail alerts on retention modifications. Backup job success/failure metrics. Snapshot age and count trends.
    10 Example Evidences Config compliance snapshots. Backup retention policy per service. Restore test reports. Backup job completion logs.

  6. Conduct gap analysis: Discover potential gaps in your compliance posture.

    • Conduct data protection impact assessments (DPIAs) where there is a high risk of non-compliance because of the location and sensitivity of the data involved.

    • To identify compliance issues, enable AWS Security Hub CSPM. Then, enable a Security Hub CSPM standard to automatically start collecting data about noncompliant resources.

  7. Log and manage risks: Maintain a risk register. Log and manage compliance-related risks that can't be addressed by the current design. Document compensatory measures applied to mitigate risks.

  8. Maintain the baseline as regulations evolve: Update your compliance baseline as regulations change. Validate requirements through reviews with stakeholders such as legal experts and your compliance teams. Document the potential economic impact of meeting regulations (cost of compliance) to guide yearly planning and budgeting.

Resources

Related best practices:

Related documents:

Related videos:

Related examples:

Related services: