PCI DSS readiness

The Payment Card Industry Data Security Standard, published by the PCI Security Standards Council and currently at version 4.0.1, is the baseline of technical and operational requirements for protecting payment account data. Aegentra defines the cardholder data environment, selects the right validation route, assesses the gap against the requirements, plans the remediation and builds the evidence pack. A Qualified Security Assessor performs formal assessments. Aegentra is not a QSA.

Scope first, because scope is where formal assessments go wrong.

PCI DSS v4.0.1 is the baseline of technical and operational requirements for protecting payment account data, and the acquirer or payment brand decides whether and how you validate against it. We trace card data through the business, draw the cardholder data environment and look for the ways it can shrink, confirm the validation route with your acquirer, assess each applicable requirement with evidence and build the remediation plan and evidence pack. A Qualified Security Assessor performs formal assessments and an Approved Scanning Vendor performs external scans. Aegentra is neither.

At a glance

• v4.0.1 the current version of PCI DSS, listed with its Summary of Changes from v4.0 in the Council’s Document Library
• 3 questions readiness answers before anyone pays for a formal assessment: what must be validated, by which route, and how far the environment is from the requirements
• 2 validation routes for merchants: a Self-Assessment Questionnaire with an Attestation of Compliance, or a Report on Compliance by a Qualified Security Assessor
• None card numbers or sensitive authentication data are ever sent to Aegentra; the work is done on flows, systems and records

The twelve requirements, in six goals

PCI DSS v4.0.1 groups its twelve requirements under six goals. Choose a requirement to see what readiness checks for it; a Qualified Security Assessor, not Aegentra, performs the formal assessment.

PCI DSS v4.0.1, 12 requirements.

Build and maintain a secure network and systems (Requirements 1 to 2)

• Requirement 1: Install and maintain network security controls. Card data flows mapped and the segmentation that keeps the rest of the business out of scope assessed with evidence.
• Requirement 2: Apply secure configurations to all system components. Each in-scope system component assessed against the requirement with the evidence examined; every gap gets an owner.

Protect account data (Requirements 3 to 4)

• Requirement 3: Protect stored account data. Stored sensitive authentication data found and removed; stored cardholder data challenged against a business need.
• Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks. Card data traced from acceptance channel through transmission, third parties included, so each open-network path is assessed.

Maintain a vulnerability management program (Requirements 5 to 6)

• Requirement 5: Protect all systems and networks from malicious software. Assessed with evidence against the cardholder data environment; the remediation plan records the gap, the owner and the closure evidence.
• Requirement 6: Develop and maintain secure systems and software. Assessed with evidence, hosted payment pages and served scripts included; policies, procedures and records built to the requirement.

Implement strong access control measures (Requirements 7 to 9)

• Requirement 7: Restrict access to system components and cardholder data by business need to know. Access to system components and cardholder data assessed against business need; third-party responsibilities listed per requirement.
• Requirement 8: Identify users and authenticate access to system components. Assessed with the evidence examined, never filled in from memory; gaps ordered by risk and dependency in the remediation plan.
• Requirement 9: Restrict physical access to cardholder data. Assessed with evidence inside your environment; the evidence pack indexes the records by requirement so a QSA can test from them.

Regularly monitor and test networks (Requirements 10 to 11)

• Requirement 10: Log and monitor all access to system components and cardholder data. Logging and monitoring of access to the cardholder data environment assessed with evidence; records built to the requirement.
• Requirement 11: Test security of systems and networks regularly. Penetration testing and ASV scans are scoped separately, through our penetration testing service or your provider; Aegentra is not an ASV. Penetration testing through Harden

Maintain an information security policy (Requirement 12)

• Requirement 12: Support information security with organizational policies and programs. Policies, procedures and records built to the requirement inside your environment and indexed in the evidence pack by requirement.

Requirement titles as published in PCI DSS v4.0.1 by the PCI Security Standards Council; the goal names are the standard’s principal requirement groups.

Who it applies to

The request comes from the acquirer or the payment brand, directly or through a customer contract, and it usually arrives as a validation requirement with a due date.

• Merchants asked by their acquirer to complete a Self-Assessment Questionnaire and Attestation of Compliance
• Service providers whose customers require a Report on Compliance from a Qualified Security Assessor
• SaaS and platform businesses that touch card data in ways their architecture diagrams do not show, including hosted payment pages and served scripts
• Organisations moving from one validation route to another as volumes or services change
• Australian subsidiaries asked by a parent or a payment brand to show the state of their cardholder data environment

What we deliver

Every system that stores, processes or transmits cardholder data, every connected system and every system that could affect their security is in scope until it is shown not to be.

• Card data flows mapped from acceptance channel to storage, processing and transmission, including third parties
• The cardholder data environment and connected systems identified, with the segmentation that keeps the rest of the business out of scope, and a scope statement a QSA can test
• Stored sensitive authentication data found and removed; stored cardholder data challenged against a business need
• The validation route confirmed in writing with your acquirer or payment brand, and the Self-Assessment Questionnaire type matched to the acceptance channels
• Each applicable requirement of PCI DSS v4.0.1 assessed with evidence, with a remediation plan ordered by risk and dependency and an owner per gap
• An evidence pack indexed by requirement, third-party responsibility matrices, and preparation for the QSA engagement where a Report on Compliance is required

What we do not do

Readiness prepares you for the assessor or for your own self-assessment; it is not the assessment.

• Aegentra is not a Qualified Security Assessor, does not perform formal PCI DSS assessments and does not issue Reports on Compliance
• Aegentra is not an Approved Scanning Vendor; external vulnerability scans are arranged with an ASV qualified by the Council
• Requirement 11 penetration testing is scoped separately, through our penetration testing service or your chosen provider, so its cost and independence are visible
• We do not accept card numbers or sensitive authentication data, and we do not accept screenshots in place of the records they depict
• Technical remediation and ongoing operation of the controls stay with your team or your providers as separate scopes

Four workstreams, in the order a formal assessment tests them.

Readiness answers what must be validated, by which route and how far the environment is from the requirements, before anyone pays for a formal assessment.

Scope and the cardholder data environment

Card data traced from each acceptance channel through storage, processing and transmission, including third parties; the environment drawn, with the segmentation that keeps the rest of the business out of scope.

Gap assessment

Each applicable requirement of PCI DSS v4.0.1 assessed against the cardholder data environment with the evidence examined, the gap and the remediation needed; nothing is filled in from memory.

Remediation plan

Gaps ordered by risk and dependency with an owner, dates and the evidence that will show closure; policies, procedures and records built to the requirement inside your environment.

Evidence pack

Indexed by requirement, with third-party responsibility matrices, so the questionnaire can be answered, or the QSA can test, from records that already exist.

Choosing the validation route

The route depends on the entity type, the acceptance channels and what the acquirer or payment brand requires. Merchants validate either through a Self-Assessment Questionnaire and an Attestation of Compliance, or through a Report on Compliance performed by a Qualified Security Assessor; the questionnaire type follows how cards are accepted. Service providers are more often required to produce a Report on Compliance. We confirm the requirement with your acquirer rather than assuming it, because the acquirer decides.

• Confirmation of what your acquirer or payment brand requires: questionnaire or Report on Compliance, and by when
• Selection of the Self-Assessment Questionnaire type that matches the acceptance channels and the cardholder data environment
• Where a Report on Compliance is required, preparation for the Qualified Security Assessor engagement, including the scope statement and the evidence pack
• Approved Scanning Vendor external scans arranged with an ASV qualified by the Council; Aegentra is not an ASV
• Attestation of Compliance prepared from the evidence rather than signed on hope

The self-assessment route against the assessor route.

Your acquirer or payment brand decides which applies; we confirm it in writing before the readiness work is aimed at either.

How the engagement runs

Named steps, each with what happens and what you receive.

Scope: Trace the card data and draw the environment

Card data is traced from each acceptance channel through storage, processing and transmission, including third parties. The cardholder data environment and its connected systems are drawn, and the ways it can shrink are tested: tokenisation, hosted payment pages, segmentation and the removal of stored data nobody needs.

What you receive:

• Card data flow maps including third parties
• A cardholder data environment definition and the segmentation that keeps the rest of the business out of scope
• A fixed-fee quote for the agreed scope

Acceptance channels → Card data flows → Cardholder data environment

Route: Confirm the validation route with the acquirer

The route depends on the entity type, the acceptance channels and what the acquirer or payment brand requires, so we confirm it with them in writing rather than assuming it. The Self-Assessment Questionnaire type is matched to the acceptance channels; where a Report on Compliance is required, the QSA engagement is prepared.

What you receive:

• The requirement confirmed: questionnaire or Report on Compliance, and by when
• The questionnaire type selected for your channels
• A scope statement a QSA can test

Acquirer or payment brand requirement → Questionnaire type or Report on Compliance → Confirmed route and deadline

Assess: Assess each applicable requirement with evidence

With scope and route settled, each applicable requirement of PCI DSS v4.0.1 is assessed against the cardholder data environment, recording the gap, the evidence examined and the remediation needed. Nothing is filled in from memory.

What you receive:

• A gap per requirement with the evidence examined
• Stored sensitive authentication data identified for removal
• Third-party service providers listed with the responsibility for each requirement they operate

Applicable requirements → Evidence examined → Gap per requirement

Plan: Order the remediation and build the records

The remediation plan is ordered by risk and dependency with an owner and the evidence that will show closure. Policies, procedures and records are built to the requirement inside your environment; Requirement 11 testing and scanning are arranged through our penetration testing service or your provider, with ASV scans by a vendor qualified by the Council.

What you receive:

• A remediation plan with owners, dates and closure evidence
• Policies, procedures and records built to the requirement
• Testing and ASV scans arranged with the scope tied to the cardholder data environment

Gaps → Remediation plan with owners → Testing and scans, separately scoped

Validate: Answer the questionnaire or hand over to the QSA

The evidence pack is indexed by requirement so the questionnaire can be answered, or the QSA can test, from records that already exist. The Attestation of Compliance is prepared from the evidence; the formal assessment, where required, is performed by the Qualified Security Assessor.

What you receive:

• An evidence pack indexed by requirement
• The Attestation of Compliance prepared from the evidence
• QSA preparation where a Report on Compliance is required

Evidence pack by requirement → Self-assessment, or QSA assessment outside Aegentra → Attestation to the acquirer

What PCI DSS is and who it applies to

PCI DSS was developed by the PCI Security Standards Council to encourage and enhance payment card account data security and to provide a baseline of technical and operational requirements designed to protect payment account data. The Council’s intended audience is any entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could impact the security of the cardholder data environment: merchants, processors, acquirers, issuers and service providers. Whether an entity must comply with or validate compliance to the standard is at the discretion of the organisations that manage compliance programs, such as a payment brand or an acquirer.

• Current version: PCI DSS v4.0.1, listed with its Summary of Changes from v4.0 in the Council’s Document Library
• A merchant is any entity that accepts payment cards bearing the logos of a participating payment brand as payment for goods or services
• A service provider is an entity, other than a payment brand, directly involved in processing, storing or transmitting cardholder data on behalf of another entity, including those whose services could impact its security
• Cardholder data consists at a minimum of the full primary account number, and may include the cardholder name, expiration date and service code
• The cardholder data environment is the system components, people and processes that store, process or transmit cardholder data or sensitive authentication data, and the components connected to them

Who asks for PCI DSS readiness

The request comes from the acquirer or the payment brand, directly or through a customer contract, and it usually arrives as a validation requirement with a due date. The entity then has to work out what it must validate, by which route, and how far it is from the requirements. Readiness work answers those three questions before anyone pays for a formal assessment.

• Merchants asked by their acquirer to complete a Self-Assessment Questionnaire and Attestation of Compliance
• Service providers whose customers require a Report on Compliance from a Qualified Security Assessor
• SaaS and platform businesses that touch card data in ways their architecture diagrams do not show
• Organisations moving from one validation route to another as volumes or services change
• Australian subsidiaries asked by a parent or a payment brand to show the state of their cardholder data environment

Scope and the cardholder data environment

Scope is the decision that drives cost and risk. Every system that stores, processes or transmits cardholder data, every connected system and every system that could affect their security is in scope until it is shown not to be. We trace card data through the business, draw the cardholder data environment, and look for the ways it can shrink: tokenisation, hosted payment pages, segmentation and the removal of stored data that nobody needs.

• Card data flows mapped from acceptance channel to storage, processing and transmission, including third parties
• The cardholder data environment and connected systems identified, with the segmentation that keeps the rest of the business out of scope
• Stored sensitive authentication data found and removed; stored cardholder data challenged against a business need
• Third-party service providers listed with the responsibility for each requirement they operate
• A scope statement a QSA can test, because scoping is where formal assessments most often go wrong

Gap assessment, remediation plan and evidence pack

With the scope and the route settled, we assess each applicable requirement against the cardholder data environment and record the gap, the evidence examined and the remediation needed. The output is a plan with owners and dates, and an evidence pack organised by requirement so the questionnaire can be answered, or the QSA can test, from records that already exist.

• Each applicable requirement of PCI DSS v4.0.1 assessed with evidence, not a questionnaire filled in from memory
• Remediation plan ordered by risk and dependency, with the owner and the evidence that will show closure
• Policies, procedures and records built to the requirement, inside your environment
• Penetration testing and vulnerability scanning for Requirement 11 arranged through our penetration testing service or your chosen provider, with the scope tied to the cardholder data environment
• The evidence pack indexed by requirement, so the trace from the attestation to the record is short

Frequently asked questions

Is Aegentra a Qualified Security Assessor?

No. Qualified Security Assessor companies are independent security organisations qualified by the PCI Security Standards Council to validate an entity’s adherence to PCI DSS, and the Council re-qualifies them each year. Aegentra is not a QSA, does not perform formal PCI DSS assessments and does not issue Reports on Compliance. We prepare you for the QSA, or for your own self-assessment, and we check the Council’s list before recommending any assessor.

Do we need a QSA or can we self-assess?

Your acquirer or payment brand decides. Merchants are often able to validate through a Self-Assessment Questionnaire and an Attestation of Compliance; service providers and larger merchants are more often required to produce a Report on Compliance from a Qualified Security Assessor. The first thing we do is confirm the requirement with your acquirer in writing, because readiness work aimed at the wrong route is wasted.

What is the cardholder data environment and why does scope matter so much?

The Council defines the cardholder data environment as the system components, people and processes that store, process or transmit cardholder data or sensitive authentication data, together with the components connected to them or that could affect their security. Everything in it is subject to the requirements. Reducing scope, through tokenisation, hosted payment pages, segmentation and not storing data you do not need, is usually the biggest cost saving available, and a scope statement that does not hold up is the most common reason a formal assessment fails.

What changed in PCI DSS v4.0.1?

The Council publishes PCI DSS v4.0.1 together with a Summary of Changes from v4.0 in its Document Library, and that document is the authoritative account of what moved. We work from the current version and the Council’s own change summary rather than paraphrasing it, and we confirm with your acquirer which version your validation is assessed against.

Does the readiness engagement include penetration testing?

Testing is scoped separately so its cost and its independence are visible. Requirement 11 testing and scanning can be arranged through our penetration testing service, with the scope tied to the cardholder data environment, or through your chosen provider. External vulnerability scans must be performed by an Approved Scanning Vendor qualified by the Council; Aegentra is not an ASV and arranges those with one.

How does PCI DSS relate to SOC 2 and ISO 27001?

They answer different questions for different audiences. PCI DSS is a prescriptive standard for payment account data required by acquirers and payment brands. SOC 2 is an attestation report on controls relevant to a service organisation’s agreed system, issued by a licensed CPA firm. ISO 27001 is a certifiable management-system standard with risk-selected controls. A business that needs more than one can reuse evidence across them, and we map rather than duplicate, but none of them substitutes for another in a contract that names one.

We are a SaaS company that never sees card numbers. Are we in scope?

Possibly. If a payment page you host, a script you serve or a system you operate could impact the security of cardholder data, the Council’s definition of a service provider can reach you even where the card number never lands in your database. The data flow mapping settles it, and the answer decides whether you need to validate and by which route. We would rather tell you that you are out of scope with the reasoning written down than let an acquirer decide it for you.

What evidence will the QSA or the questionnaire need?

Records that show each applicable requirement operates: network and data flow diagrams, configuration standards, access reviews, logging and monitoring records, scan and test reports, policies and the records of their operation, and third-party responsibility matrices. We build the evidence pack indexed by requirement so the trace from the attestation to the record is short, and we do not accept screenshots in place of the records they depict.

Do you handle card data during the engagement?

No. The work is done on data flows, system configuration, policies and records. We do not ask for card numbers or sensitive authentication data and we do not accept them if offered; finding stored sensitive authentication data in your environment is a finding, not something we take a copy of.

What does PCI DSS readiness cost?

It is scoped and quoted as a fixed fee after a scoping call. The drivers are the acceptance channels, the size of the cardholder data environment, the validation route, the number of third parties and the state of the existing controls. QSA fees, ASV scan fees and penetration testing are separate and quoted on their own, so each part of the cost is visible before you commit.

Scope and boundaries

What is in the scope, what is quoted separately and what we never do.

Tell us how you take payments.

Share your acceptance channels, what your acquirer or payment brand has asked for and by when, and whether you are a merchant, a service provider or both. A practitioner replies with the readiness scope and a fixed fee. Do not send card data.

Where the service fits

Related Aegentra services

• Penetration testing (Requirement 11 testing)
• SOC 2 readiness
• ISO 27001 consulting and implementation
• SOC 2 or ISO 27001?

Related PECB courses

• PECB Lead SOC 2 Manager course

Training, implementation, internal audit and independent certification have separate scopes and fees.

Requirement 11 testing is scoped to the cardholder data environment through our penetration testing service. Service organisations that are also asked for an attestation report can read about SOC 2 readiness, and the differences between the two assurance routes and ISO 27001 are set out in SOC 2 or ISO 27001?.

Where we work

Teams in Melbourne and Sydney. Delivered across all Australian states and territories, remotely or onsite by arrangement. New Zealand and Asia Pacific by arrangement.