Standards in Practice: ISO 27001 and PCI DSS

What you'll be able to do

• ›Distinguish ISO 27001 readiness, certification, surveillance, and recertification
• ›Trace clauses 4 to 10 through risk treatment, the SoA, and operating evidence
• ›Define PCI DSS scope using payment flows, security dependencies, and tested segmentation
• ›Choose PCI validation and exception routes without confusing SAQ, ROC, or customization
• ›Judge ISO and PCI evidence against specific claims and document defensible findings

Brief: two assurance boundaries

Information security management system (ISMS). Data Security Standard (DSS). A driving licence and a vehicle inspection prove different things. Two assurance claims can also cover different boundaries. At fictional Copper Finch Tickets, the engineering team operates a booking platform and a payment service. Leadership wants an International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 27001 certificate for the booking operation. It also wants a Payment Card Industry Data Security Standard (PCI DSS) assessment covering payment processing. The sales team assumes either result proves every system is secure. Your job is to separate the claims, map dependencies, and request evidence that supports each conclusion.

ISO/IEC 27001:2022 assesses an information security management system, or ISMS, within a defined scope. PCI DSS v4.0 is a payment security standard with technical and operational requirements for entities that store, process, or transmit payment account data. Also, Systems that can affect its security. A certificate does not replace PCI validation. Neither assessment eliminates ongoing operational responsibilities. Use the current PCI DSS v4.x documents, currently v4.0.1, when performing a real assessment. Requirements that were future dated to 31 March 2025 are now effective.

Certification is a cycle, not a launch event

One clean kitchen inspection does not keep the kitchen clean forever. Certification also needs continuing work and later checks. Stage 1 reviews ISMS documentation and readiness for stage 2. The certification body examines the proposed scope, context, risk assessment and treatment approach, internal audit and management review status, and preparedness for implementation assessment. It can identify readiness concerns. It does not itself award certification or establish that controls have operated effectively.

Stage 2 evaluates implementation and effectiveness through interviews, sampling, records, and observed operation across the scoped ISMS. A policy dated yesterday cannot establish a year of access reviews. Findings need correction and corrective action appropriate to their significance. Certification decisions follow the certification body process rather than a project manager declaring the findings closed.

Certification often runs on a three-year cycle with surveillance visits between initial certification and recertification. The first surveillance is due no later than 12 months after the certification decision. Surveillance normally occurs at least annually. Surveillance samples continued conformity and improvement, including changes, previous findings and internal assurance. Recertification evaluates continued suitability and effectiveness before renewal. Verify the actual certificate scope, dates, sites, and certification body rather than relying on a logo in a proposal.

Clauses 4 to 10 connect decisions to results

A household plan connects goals, responsibilities, daily work, and reviews. A management system connects decisions to results in a similar way. Clause 4 addresses organizational context, interested parties, and the ISMS scope. Clause 5 concerns leadership, policy, and assigned responsibilities. Clause 6 covers planning, including risk assessment and treatment, security objectives, and planned changes. At Copper Finch, these clauses connect a booking availability objective to a named owner, risk criteria, dependencies. Also, Funded action rather than a generic security promise.

Clause 7 supports delivery through resources, competence, awareness, communication, and controlled documented information. Clause 8 concerns operational planning and control, risk assessment, and implementation of risk treatment. Trace a privileged-access risk from the assessment to its treatment plan, an approved operating procedure, and records showing the procedure was followed.

Clause 9 covers monitoring, measurement, internal audit, and management review. Clause 10 addresses continual improvement and nonconformity, a failure to meet a requirement, with corrective action. A useful trace ends with results reviewed by management, a decision when performance misses its objective, and evidence that the response worked. Clauses 4 to 10 are management-system requirements, not an optional menu of technical controls.

Annex A and the Statement of Applicability

A shopping checklist helps you avoid missing something, but not every item belongs in your basket. A control reference list also needs reasoned selection. Annex A in the 2022 edition contains 93 reference controls grouped into organizational, people, physical, and technological themes. Select necessary controls through risk treatment and relevant obligations, then compare them against Annex A so necessary controls are not overlooked. Additional controls may be needed. Implementing every Annex A control mechanically does not demonstrate an effective ISMS.

The Statement of Applicability, or statement of applicability (SoA), identifies necessary controls, explains their inclusion, records whether they are implemented. Also, Justifies exclusions of Annex A controls. Link it to risk treatment and supporting evidence. A scope statement explains the ISMS boundary. The SoA explains control applicability inside that context. Do not use an SoA exclusion to waive a clause 4 to 10 requirement.

Suppose Copper Finch excludes a physical control because it uses hosted infrastructure. Ask what the control is intended to address and which offices or equipment still exist. Also, What the provider actually does. A provider contract and assurance report may support a shared-responsibility explanation. The word cloud alone does not justify exclusion. Flag an unsupported rationale and investigate the evidence before grading the nonconformity, a failure to meet a requirement,.

PCI scope follows data and security influence

A locked room can still be affected by someone who controls its keys. Payment security boundaries include systems that can influence protection. The cardholder data environment (CDE) comprises people, processes, and technologies storing, processing, or transmitting cardholder data or sensitive authentication data. The primary account number, or primary account number (PAN), is central to identifying cardholder data. Sensitive authentication data, such as card verification codes and full track data, must not be retained after authorization even if encrypted. Redaction, encryption, and tokenization require careful analysis. Encryption alone does not remove a system from scope.

Start with transaction entry points and map authorization, settlement, refunds, support, logs, backups, and disposal. Include connected-to and security-impacting systems such as administrator jump hosts, identity services, deployment systems and segmentation devices where they can affect CDE security. Outsourcing payment processing does not remove the merchant obligation to confirm provider responsibilities and applicable validation.

Segmentation can reduce scope only when it effectively isolates out-of-scope systems from the CDE. A virtual local area network (VLAN) name or firewall diagram is a design claim, not proof. Inspect rule sets and routes, sample permitted and denied flows, and test isolation from relevant out-of-scope networks. PCI segmentation testing is required at least annually and after changes for applicable entities. Service providers have a six-month frequency. Confirm scope at least annually and upon significant change, with additional service-provider obligations. Failed isolation means revisiting scope, not preserving an exclusion by renaming a subnet.

Navigate the 12 principal requirements

A house needs more than a front-door lock. Payment security also brings together several kinds of protection. Use requirement numbers as an evidence index, not a copied checklist. Requirements 1 and 2 address network security controls and secure system configurations. Requirements 3 and 4 concern stored account data protection and strong cryptography for transmission over open, public networks. For Copper Finch, compare network rules with the data-flow map, check hardening exceptions, inspect retention and deletion jobs, and verify the actual payment transmission paths.

Requirements 5 and 6 address malicious software defenses and secure development and maintenance. Requirements 7 and 8 concern access restriction and user identification and authentication. Requirement 9 covers physical access. Seek deployed protections and exception reviews, vulnerability work to fix the problem records, change approvals, role assignments, authentication configurations, and relevant site access records. A license purchase is not evidence that a defense operated on every applicable system.

Requirement 10 covers logging and monitoring, requirement 11 security testing, and requirement 12 policies and the organizational security program. Correlate logs with alert review records, verify scan and penetration-test scope and work to fix the problem retests. Also, Inspect incident readiness, provider oversight, and documented scope confirmation. Each principal requirement has detailed applicability and testing expectations. A green dashboard for one sample cannot establish conformity across the full population.

Validation: SAQ, ROC, and responsibility

A short application form and a detailed inspection report serve different needs. The required validation route depends on the applicable rules. A Self-Assessment Questionnaire, or self-assessment questionnaire (SAQ), supports eligible self-assessment. The correct SAQ depends on the payment channel and all eligibility criteria, not just transaction volume or a preference for fewer questions. A Report on Compliance, or report on compliance (ROC), documents a detailed assessment by an appropriate assessor under the applicable program. The acquiring bank or payment brand determines the required validation route. Do not assume every small merchant can use any SAQ or that every ROC must follow the same assessor arrangement.

An Attestation of Compliance, or attestation of compliance (AOC), records the assessment outcome and scope in the prescribed format. It is not a substitute for examining the underlying basis when evidence is needed. Match provider service names, dates, covered locations, and responsibility allocations to the service actually consumed. Copper Finch must still operate its retained controls and assess integrations even when its payment processor supplies a current AOC.

Before accepting a hosted checkout scope reduction, document whether account data enters merchant systems and which merchant components can affect the payment journey. A webpage, script deployment path, or support workflow may change eligibility. Record the exact implementation and confirm the applicable current SAQ criteria with the acquirer rather than inferring eligibility from the phrase outsourced payments.

Exceptions are not interchangeable shortcuts

A different lock is not automatically an acceptable substitute for a required lock. Exceptions need their own conditions and evidence. A compensating control addresses a legitimate technical or documented business constraint preventing an entity from meeting a stated requirement as written. It must meet the intent and rigor of the original requirement, provide a similar level of defense, go above and beyond other PCI DSS requirements. Also, Address the additional risk. Document the constraint, objective, risk, control, validation, and maintenance in the applicable compensating-controls worksheet. Cost preference or a manager signature alone is not enough.

The customized approach permits a different control design to meet a requirement customized-approach objective where that approach is allowed. It needs mature risk management, documented controls and supporting evidence, a targeted risk analysis, and assessor-developed testing procedures appropriate to the design. It is not the same as a compensating control, and it does not require the same inability-to-meet-as-written constraint. SAQs do not support the customized approach. Agree the assessment route and assessor responsibilities before using it.

If Copper Finch proposes a home-grown authentication design, first determine whether the requirement supports customization and whether the design meets its objective. A targeted risk analysis is not a blanket risk acceptance allowing noncompliance. Where a requirement permits risk-based activity frequencies, the relevant targeted analysis supports that specific decision rather than authorizing arbitrary exceptions elsewhere.

Write findings that can be closed with evidence

A repair note should say what failed and how someone will check the fix. An audit finding needs the same clear links. An ISO finding might show the SoA claims access reviews are implemented while no reviews occurred in the sampled period. A PCI finding might show a supposedly isolated reporting network can reach payment servers, or post-authorization verification codes appear in debug logs. State the criterion, observed condition, affected population, dates, evidence identifiers, and consequence. Avoid turning every document typo into a major finding or accepting serious operational failures as paperwork gaps.

Separate correction from corrective action: remove prohibited data or block an unauthorized route now, then address how logging configuration or change review allowed the failure. ISO major or minor classification depends on significance to the management system and the certification body process, not a universal points formula. For PCI, report the applicable requirement result and evidence under the relevant reporting instructions rather than borrowing ISO classification labels.

Closure requires implementation evidence and verification against the original failure. Inspect sanitized logs and retention behavior after the fix, retest segmentation from relevant paths, and sample subsequent access reviews for scope and approval quality. A change ticket marked complete is an assertion. In the labs, record a specific payment boundary and judge narrow evidence claims without inventing broader certification or compliance conclusions.