Security · International (PCI SSC)

PCI DSS v4.0.1 (Requirements 6 and 11)

Attestkeep maps what your cluster's admission control and image scanning recorded in a period to 13 clauses of PCI Security Standards Council, Payment Card Industry Data Security Standard, version 4.0.1 (June 2024). 8 are assessed from those records; 5 are marked outside scope, each with the reason.

Create an account How a package is built

What the framework asks

8 clauses a cluster can answer.

Citations and titles as the report prints them. Open a clause to read what it asks, restated close to the instrument's own words.

PCI DSS v4.0.1

PCI Security Standards Council, Payment Card Industry Data Security Standard, version 4.0.1 (June 2024)

Requirement 6.3 and 6.5 (vulnerability management and change control), Requirement 10.2 (audit logs) and Requirement 11.3 (internal vulnerability scanning)

Citation	Clause	Report sections
Requirement 6.3.1	Security vulnerabilities are identified and risk-ranked New security vulnerabilities are identified using industry-recognised sources for vulnerability information, including alerts from national and international computer emergency response teams, and are assigned a risk ranking that identifies at least all vulnerabilities considered high risk or critical to the environment, and vulnerabilities for bespoke and custom, and third-party software, such as operating systems and databases, are covered.	CoverageClusterAdmission decisionsOutcomesDeployment contextControl statement
Requirement 6.3.2	Inventory of bespoke, custom and third-party software components An inventory of bespoke and custom software, and of the third-party software components incorporated into it, is maintained to facilitate vulnerability and patch management.	Supply chainCoverage
Requirement 6.3.3	System components are protected from known vulnerabilities by patching All system components are protected from known vulnerabilities by installing applicable security patches, with patches for critical vulnerabilities, identified according to the risk ranking process at Requirement 6.3.1, installed within one month of release, and all other applicable security patches installed within an appropriate time frame as determined by the entity's assessment of the criticality of the risk.	Control statementCoverageAdmission decisionsOutcomes
Requirement 6.5.1	Changes to system components follow change control procedures Changes to all system components in the production environment are made according to established procedures covering the reason for and description of the change, documented security impact, documented approval by authorised parties, testing to verify that the change does not adversely impact system security, testing of bespoke and custom software updates for compliance with Requirement 6.2.4 before being released into production, and procedures to address failures and return to a secure state.	Admission decisionsEvidence chain
Requirement 10.2.2	What each audit log entry records Audit logs record, for each auditable event, the user identification, the type of event, the date and time, a success or failure indication, the origination of the event, and the identity or name of the affected data, system component, resource or service.	Evidence chain
Requirement 11.3.1	Internal vulnerability scans at least once every three months Internal vulnerability scans are performed at least once every three months, high-risk and critical vulnerabilities are resolved, rescans confirm that they have been resolved, the scanning tool is kept current with vulnerability information, and scans are performed by qualified personnel with organisational independence of the tester.	CoverageAdmission decisionsOutcomesControl statementIssues
Requirement 11.3.1.1	Vulnerabilities not ranked high-risk or critical All other applicable vulnerabilities are managed by addressing them according to the risk defined in the entity's targeted risk analysis, with rescans conducted as needed.	Triage decisionsCoverageDeployment context
Requirement 11.3.1.2	Internal scans are performed via authenticated scanning Internal vulnerability scans are performed via authenticated scanning, with sufficient privileges used for the systems that accept credentials, with those unable to accept them documented, and with any account used for authenticated scanning that can also be used for interactive login managed in accordance with Requirement 8.2.2.	Coverage

5 clauses marked outside scope, and why

Citation	Clause and reason
Requirement 6.4.2	Automated protection for public-facing web applications this control decides which image may run; it sees none of the traffic the application then answers, which is where a web-based attack arrives
Requirement 6.4.3	Payment page scripts are authorised, integrity-assured and inventoried the scripts a payment page serves to a browser are content the application produces at run time, below the image this control admits and invisible to it
Requirement 10.2.1	Audit logs are enabled and active logging is enabled component by component across the entity's environment; this document evidences the log this control keeps of its own decisions, which 10.2.2 below reports, and can say nothing about the rest
Requirement 11.3.2	External vulnerability scans by an Approved Scanning Vendor an ASV scans the entity's external attack surface from outside it and reports under the ASV Program Guide; nothing about that engagement is observable from inside a cluster
Requirement 12.3.1	Targeted risk analysis for a frequency the entity sets the analysis that sets the frequency for 11.3.1.1 is a document the entity writes, approves and reviews; this control operates at whatever frequency that analysis lands on and cannot stand in for it

What Attestkeep produces

Evidence from records the cluster already keeps.

Nothing is filled in by hand. Each clause's answer carries a status (met, partial, gap or outside scope), a note with the period's own numbers, and the report sections those numbers come from.

Statements the mapping draws on

Each assessed clause is answered by one or more of these statements about the period's records. The same statement answers the same question under every framework, so two reports for one period cannot disagree.

Every image in the inventory carries a scan record4 clauses
Images carrying severe findings are refused3 clauses
Every decision and administrative action is recorded2 clauses
Vulnerability thresholds are stricter where the workload is exposed or privileged2 clauses
Admission refuses non-compliant workloads1 clause
Every image change is recorded against the policy that governed it1 clause
Accepted risks are named, justified and expire1 clause
Findings are matched against a national catalogue of exploited vulnerabilities1 clause
Critical findings carry a remediation window of no more than one month1 clause
Remediation windows are declared for each severity1 clause
A bill of materials is held for the images in service1 clause
Images are scanned as an authenticated pull with the workload's own credentials1 clause

The package

What the report contains.

Every package carries the same sections, whatever the framework. The ones marked are those PCI DSS answers cite, with the number of clauses citing each.

The scope paragraph, as the report states it.

This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto PCI DSS v4.0.1. It is not a Report on Compliance and not an Attestation of Compliance: those are issued by a Qualified Security Assessor or a qualified internal resource against the entity's whole cardholder data environment, and only the entity defines what is in that environment. Nothing here establishes that this cluster is in scope for PCI DSS, or that it is out of it. What the period's records support is the vulnerability management clauses of Requirement 6 and the internal scanning clauses of Requirement 11 for the images this cluster admitted, together with the audit log clauses of 10.2 for the decisions it took. The document records the version of the CISA Known Exploited Vulnerabilities catalogue the period's decisions were taken against, which is one of the industry-recognised sources Requirement 6.3.1 asks for; the mapping below reads the scan and admission records rather than that catalogue directly. Account data at rest and in transit, the web application and payment page clauses of 6.4, the Approved Scanning Vendor scans of 11.3.2 and the organisational programme of Requirement 12 are outside what a cluster observes and are marked as such.

Questions

About PCI DSS and Attestkeep

Is this a PCI DSS certification?

No. The package is evidence produced from your cluster's own records. It is not a certification, and no auditor is obliged to accept it. The scope paragraph on this page is the one the report itself carries.

Why are 5 of the clauses outside scope?

They ask about things one cluster's admission and scanning records cannot show. They are listed with the reason rather than left out, so whoever reads the report can see the gap is deliberate.

Which plan includes PCI DSS?

Every plan can report against it. Community and Team include one framework of your choice, Business three, Enterprise every one. Prices are on the pricing page.

How does an auditor check the package?

In a browser at attestkeep.com/verify.html, where nothing is uploaded, or with the short script on the documentation site. Neither needs us. For auditors has the details.

Install it yourself.

Create an account, confirm your e-mail with the code we send, take the free Community key from the Licenses page, and install with Helm.

Create an account