Compliance standards, and what an auditor actually asks for

Why this matters

CompTIA names PCI DSS, SOC 2 and ISO 27001 explicitly in this objective, which tells you the depth expected: know what each one is, who it serves, and what your obligations look like in a shared-responsibility world.

The idea that does the real work is that compliance is shared and never delegated. A provider's certification covers the provider's half. It says nothing about whether you configured your half correctly, and an auditor will not accept it as though it did. Candidates who understand where that line falls answer most of this objective correctly; candidates who think "we use a compliant provider, so we are compliant" get it wrong in a specific and predictable way.

The lesson

PCI DSS, SOC 2 and ISO 27001 in one sentence each, and who each one serves

PCI DSS — the Payment Card Industry Data Security Standard. A prescriptive contractual standard applying to anyone who stores, processes or transmits payment card data. It is not law; it is imposed by the card brands through your acquiring bank, and it tells you specifically what to do rather than asking you to decide. Its defining concept is scope: everything in the cardholder data environment, plus anything connected to it. Reducing scope — by segmenting the network, by tokenising card data, by never letting card numbers touch your systems — is the main strategy, because the smallest compliant environment is the cheapest one to keep compliant.

SOC 2 — a report, not a certification, produced by an independent auditor against the Trust Services Criteria: security, and optionally availability, processing integrity, confidentiality and privacy. It is what B2B service providers give customers as assurance. Two types matter and are regularly confused:

• Type I — the controls are suitably designed at a point in time.
• Type II — the controls operated effectively over a period, typically six to twelve months.

Type II is substantially more meaningful, because it tests whether you actually did the things, repeatedly, over time.

ISO/IEC 27001 — an international standard for an information security management system. Certifiable by an accredited body. Unlike PCI DSS it is not a list of technical requirements: it specifies a management system — risk assessment, treatment, documented controls, internal audit, management review and continual improvement. It is about having a functioning process, with the control set as an annex.

Others you may meet in a scenario: HIPAA (US health information), GDPR (EU personal data, and a law rather than a standard), FedRAMP (US government cloud authorisation), NIST frameworks (commonly used as a control baseline), and CSA STAR (cloud-specific assurance).

The distinction worth carrying: PCI DSS is prescriptive and contractual, SOC 2 is an attestation report, ISO 27001 is a certifiable management system, and GDPR/HIPAA are law.

The shared responsibility line drawn through a compliance scope

Objective 1.1's responsibility line reappears here as a compliance boundary, and the consequence is precise: the provider's compliance covers the provider's responsibilities only.

Using a provider certified for PCI DSS does not make your application compliant. It means the infrastructure beneath you has been assessed. Your configuration, your access control, your logging, your encryption choices, your application and your processes are still yours to evidence.

This produces the concept of inherited controls. A control framework contains requirements you can inherit wholly from the provider (physical security of the data centre, media destruction), requirements that are shared (patching — theirs below the line, yours above it), and requirements that are entirely yours (access reviews, key management, application security).

Providers publish responsibility matrices for major frameworks showing which is which. Use them, and produce your own: a document listing each requirement and stating who satisfies it and how it is evidenced. That document is what an auditor works through, and building it is most of preparing for an audit.

Two traps:

• A service being "in scope" for a provider's certification is per-service. Providers certify specific services, not entire platforms. A service outside the certification scope carries no inherited assurance, and using it inside a regulated environment means evidencing it yourself.
• The region matters. Certification scope can differ by region.

Provider attestations: what you may inherit, and what you must still evidence

The attestation documents are the provider's evidence, and knowing which one is which is examinable.

• SOC 2 Type II report — the detailed auditor's report on the provider's controls. Usually available under NDA through the provider's compliance portal, and it is what your own auditor will want to read.
• SOC 3 — a public summary of the same, suitable for sharing freely, with much less detail.
• ISO 27001 certificate plus its statement of applicability.
• PCI DSS Attestation of Compliance, and often a responsibility matrix alongside it.
• Penetration test summaries and bridge letters, the latter covering the gap between a report's period end and the current date.

How to use them properly:

• Read them, do not just file them. The reports contain complementary user entity controls — a list of things the provider explicitly states you must do for the assurance to hold. That list is effectively a set of compliance requirements handed to you, and it is routinely ignored.
• Check the period and the scope. A report covering a period that ended eight months ago needs a bridge letter. A report that does not cover the services or regions you use covers nothing you use.
• Note the exceptions. Auditor-identified exceptions are recorded in the report and are relevant to your risk assessment.
• Re-collect annually as part of vendor management, since certifications lapse and scopes change.

What you must always evidence yourself, regardless of provider: identity and access management, your configuration, your data classification and handling, your encryption and key management decisions, your logging and monitoring, your change management, your incident response, and your vendor management.

Data residency, sovereignty and the region choice that follows from them

Data residency is where data is physically stored. Data sovereignty is whose laws apply to it. They are not the same, and the difference is the point.

Residency is a technical choice: select a region in the required country and the data is stored there. Sovereignty is a legal question, and it can reach data stored elsewhere — a provider headquartered in one jurisdiction may be subject to that jurisdiction's legal process regardless of where the bytes live. That is why some regulated sectors require a provider incorporated locally, or a sovereign-cloud arrangement, rather than merely a local region.

What this means in practice:

• Choose the region deliberately, on residency requirements as well as latency and price.
• Watch the things that leave the region without anyone choosing it: backups replicated cross-region, disaster-recovery copies, logs and telemetry sent to a central account, managed services with a global control plane, content delivery caches, and support access from elsewhere. Several of these are defaults.
• Constrain it structurally. An organisation-level policy denying unapproved regions (objective 4.2) is a far stronger control than a documented intention, and it also reduces where an attacker can hide resources.
• Cross-border transfer of personal data needs a lawful basis under regimes like GDPR, and the mechanisms change over time — which is a legal question to be routed to legal, not solved by an engineer.
• Encryption with customer-held keys is a meaningful mitigation for some sovereignty concerns, because data unreadable without a key you control is materially different from data in plaintext.

Evidence: logs, configuration and approvals, produced on request rather than reconstructed

The practical heart of the objective. An auditor does not accept that a control exists; they ask you to demonstrate it, usually by sampling.

What they typically ask for:

• A list of all in-scope systems, which is the asset inventory from objective 4.1. An incomplete inventory undermines everything after it.
• Access evidence: who has access, how it was approved, evidence of periodic review, and proof that leavers were removed — often by sampling specific individuals.
• Change evidence: for a sampled change, the request, the approval, the test result and what was deployed. This is where change records (objective 3.1) and pull-request history (objective 5.2) do the work.
• Configuration evidence: that encryption is enabled, logging is on, and the baseline is met. Posture reports (objective 4.1) produce this directly.
• Vulnerability evidence: scan results, remediation within policy timescales, and documented acceptances.
• Backup and recovery evidence: that backups run and that restores were tested (objective 3.2). Auditors ask for the test results specifically.
• Log evidence: that audit logs are collected, retained for the required period, and protected from tampering.
• Incident evidence: that incidents were detected, handled and reviewed.

The sentence that matters: evidence produced continuously is cheap; evidence reconstructed at audit time is expensive and often impossible. You cannot retroactively produce an access review that did not happen, or logs beyond a retention window already passed.

So build evidence generation into normal operation: automated posture reports kept on a schedule, access reviews performed and recorded in a system, change history preserved, restore tests documented and signed, log retention set to meet the longest applicable requirement. Then an audit becomes a matter of retrieving things rather than a project.

Two further points. Immutable audit logs — write-once, deletion-protected — are worth specific attention, because a log an administrator can alter is weak evidence; the same object-lock mechanism as the backup immutability in objective 3.2. And "compliant" is a point-in-time statement: continuous monitoring is what keeps it true between assessments, which is why the posture scanning in objectives 4.1 and 6.5 is a compliance control as much as a security one.

What to take into the exam

• PCI DSS = prescriptive and contractual, scope is everything. SOC 2 = a report (Type I design at a point in time, Type II operation over a period). ISO 27001 = a certifiable management system. GDPR and HIPAA are law.
• Compliance is shared and never delegated. The provider's certification covers the provider's half; certification is per service and per region.
• Read the attestation's complementary user entity controls — they are requirements handed to you — and check its period and exceptions.
• Residency = where data sits. Sovereignty = whose law applies. Watch backups, DR copies, logs and global control planes leaving the region by default; enforce with a region-deny policy.
• Evidence generated continuously is cheap; reconstructed evidence is often impossible. Auditors specifically ask for access reviews, change approvals and restore test results.
• Audit logs should be immutable, and compliance is maintained by continuous monitoring between assessments.