PCI DSS, ISO/IEC 27000 and industry-specific obligations

Why this matters

Compliance obligations differ from everything else in this course in one respect: they are not yours to prioritise. A risk can be accepted; an obligation cannot. That single asymmetry is why compliance strategy is a distinct objective and why scenarios about it have a different shape — the question is rarely whether to comply, it is how to comply at the lowest cost and with the smallest scope.

The second reason it matters is that compliance and security diverge. A compliant organisation is not necessarily a secure one, and a secure one is not automatically compliant. Treating the two as the same thing produces either a programme that spends its budget on evidence for controls it already had, or one that is genuinely well defended and fails an assessment on documentation.

CAS-005 tests three things here: which regime applies to a described situation, what scope reduction means and why it is usually the cheapest move, and the difference between certification, attestation and self-assessment as levels of assurance.

The lesson

Scoping PCI DSS, and why reducing scope is usually cheaper than meeting it

The payment card standard applies to any system that stores, processes or transmits cardholder data — and, critically, to any system connected to or able to affect the security of those systems. That second clause is where scope explodes: a flat network makes every device in it in-scope, including printers and meeting-room displays.

The requirements are prescriptive and numerous — network controls, no vendor defaults, protection of stored data, encryption in transit, malware protection, secure development, access restricted by need to know, unique identification, physical access control, logging and monitoring, testing, and a governing policy. Applying all of that to an entire corporate estate is enormously expensive; applying it to a well-defined segment is manageable.

Hence the strategy the exam rewards: reduce scope first, then comply.

• Segment so that the cardholder data environment is a defined, tightly controlled zone with enumerated, controlled connections. Segmentation is the single largest cost lever in the standard.
• Do not store what you do not need. Stored data carries the heaviest requirements; eliminating storage removes whole requirement families.
• Tokenise, so systems downstream of the payment flow hold tokens rather than card numbers and fall out of scope — this is the commercial reason tokenisation exists, as lesson seven noted.
• Outsource the capture. Redirecting the payment page or using a provider-hosted field means the card number never touches your systems, though it does not remove all obligation — the page that redirects is still in scope, and provider due diligence still applies.

The examinable trap is segmentation that is asserted rather than tested. If the segmentation is not verified, the assessor treats the whole connected network as in scope, and an organisation that believed it had a small scope discovers it has a very large one part-way through an assessment.

A detail worth holding: compliance is contractual, enforced through the payment brands and acquirers, not a statute. The consequences are commercial — fines passed down, higher transaction costs, and in serious cases loss of the ability to accept cards.

The ISO/IEC 27000 family: 27001 as the management system, 27002 as the control set

The distinction between these two numbers is the most frequently tested fact in this objective.

ISO/IEC 27001 specifies an Information Security Management System — a management framework. Its requirements are about how the organisation manages security: context and interested parties, leadership commitment, a risk assessment and treatment process, objectives, competence, documented information, internal audit, management review, and continual improvement. You are certified against 27001, and what is certified is that the management system exists and operates.

ISO/IEC 27002 is guidance on the controls themselves — a catalogue with implementation advice, organised into themes covering organisational, people, physical and technological controls. You are not certified against 27002. It informs the controls you select.

The connection is the statement of applicability: the document listing which controls apply, whether each is implemented, and the justification for any exclusion. It is the central artefact of a 27001 certification, and it is where the risk assessment from lesson eight meets the control catalogue.

Other numbers in the family appear as distractors: 27005 covers information security risk management, 27017 and 27018 address cloud services and personal data in the cloud, and 27701 extends the management system to privacy. You do not need their contents, only the shape: 27001 is the certifiable management system and the rest are guidance or extensions.

The practical consequence is worth stating because it changes what a certification tells you about a supplier. A 27001 certificate says an organisation has a functioning system for managing security risk within a declared scope — not that it implements any particular control. Read the scope statement, every time.

Certification, attestation and self-assessment as three different levels of assurance

Three words that scenarios use precisely and candidates often treat as synonyms.

• Self-assessment. The organisation evaluates itself against a standard and declares the result. No independent verification. Its value is the written commitment and the internal discipline of producing it.
• Attestation. An independent party examines and reports. The strength depends on two variables: who the party is and what they tested. An auditor's report on the design of controls at a point in time is materially weaker than one on their operating effectiveness over a period, and that distinction is examinable.
• Certification. An accredited certification body assesses against a published standard and issues a certificate with a defined scope and expiry, subject to surveillance and recertification. The accreditation of the body is what distinguishes this from an unaccredited "certificate".

Four questions decide how much any of these is worth, and a scenario will usually hand you the one that matters:

1. Who performed it — the organisation itself, a paid consultant, or an accredited body.
2. What was in scope — one service, one site, or the whole organisation.
3. What period it covers — a day, or twelve months of operation.
4. How old it is, and what has changed since.

The characteristic failure, and it recurs in supply-chain scenarios: a supplier provides a genuine certificate whose scope covers a different service from the one being purchased. Nobody lied. Nobody read the scope.

Sector obligations that override preference: healthcare, finance, government, critical infrastructure

Beyond the general standards, sectors carry obligations that are not optional and frequently prescribe specifics that a risk assessment would not have chosen.

The recurring patterns, which is what to learn rather than any jurisdiction's particular statute:

• Healthcare. Strong protection of health records, strict rules on disclosure, breach notification with defined timelines, and obligations that flow down to anyone processing the data on your behalf.
• Financial services. Operational resilience requirements with recovery targets set by a regulator rather than by your own BIA, obligations around outsourcing and concentration risk, record retention measured in years, and direct regulatory reporting of significant incidents.
• Government and defence. Formal authorisation to operate, mandated control catalogues and baselines, personnel clearance requirements, supply-chain provenance rules, and data residency constraints.
• Critical infrastructure. Duties covering incident reporting on short clocks, minimum security measures, and increasingly the security of operational technology as well as IT.
• Privacy, which cuts across all sectors: lawful basis, data subject rights, cross-border transfer restrictions, and notification obligations triggered by awareness rather than by confirmation.

Three consequences shape a compliance strategy. Obligations stack — an organisation can be subject to several at once, and the strictest requirement governs. They flow down to suppliers through contract, which is what connects this to third-party risk. And they can conflict, most often between a retention duty and a deletion right, which is resolved by legal analysis and documented as a decision, not by whichever system was configured first.

Answering 'which standard applies' questions from the data and the sector, not the technology

Scenarios in this objective are decidable, and the decision procedure is short.

Ask what data is involved. Cardholder data pulls in the payment standard. Health records pull in healthcare regulation. Personal data of residents in a jurisdiction pulls in that jurisdiction's privacy law regardless of where the processing happens. Classified or government data pulls in the relevant authorisation regime.

Ask what sector the organisation operates in, and whether it is designated as critical or regulated.

Ask where the data subjects are, not where the servers are. Extraterritorial reach is the norm in privacy law and the most common reason a candidate picks the wrong regime.

Ask what the organisation has contractually promised, because customer security schedules are obligations with the same force as regulation and are frequently the binding constraint in a business-to-business scenario.

What does not decide it: the technology in the scenario. Cloud versus on-premises, container versus virtual machine, one provider versus another — none of these changes which regime applies. They change how you comply, and a distractor built on technology is the commonest wrong answer here.

One further note that generalises. Where several regimes apply, the practical strategy is to implement to the strictest requirement and map once — which is precisely the control-mapping work from lesson six. A programme that implements separately for each regime pays several times for the same control and has several versions of the truth about whether it works.