Control map · v4.0

PCI DSS

11 of 26 PCI DSS controls code can evidence, with v1.4.0, plus 1 supporting

Code evidence for stored and transit card data, secrets, access and secure code today; change approval in v1.4.0.

Live10
Coming in v1.4.01
Supporting1
Planned15
Your organisation36

10 with code evidence todayPartial evidence, checked on every pull request.
1 more in v1.4.0Process evidence from merges, approvals and rule changes.
36 stay with your organisationListed in full below, so nothing is implied.

Assessors test secure software and change control from change tickets, code-review records and scan results.

Today the PCI DSS blueprint gives code evidence for ten requirements, including stored-data encryption, transit encryption and service-account secrets. From v1.4.0, every merged change carries its approval as a sealed record, and the review before merge strengthens the secure-code evidence.

Toevan gives evidence for controls; it never certifies them or claims a framework is covered. Whether the evidence is sufficient is your auditor’s judgement.

Controls are shown by id with Toevan’s own short names. The official titles and requirement text belong to the framework’s publisher.

Live10

Code evidence today, sealed on every pull request. Always partial: the control also asks for things outside code. Code evidence today: rules in the PCI DSS blueprint check part of this on every pull request.

Req.1.3
Inbound traffic limits
Req.1 Network boundary rules
Req.3.3
Authentication secrets retention
Req.3 Stored data safeguards
Req.3.5
Stored data encryption
Req.3 Stored data safeguards
Req.3.6
Key protection
Req.3 Stored data safeguards
Req.4.2
Transit encryption
Req.4 Transit encryption
Req.6.2
Secure code habits
Req.6 Secure software work
Strengthened in v1.4.0: the review before merge is sealed per change.
Req.6.3
Vulnerability scanning
Req.6 Secure software work
Req.7.2
Role access rights
Req.7 Access limits
Req.7.3
System access limits
Req.7 Access limits
Req.8.6
Service account secrets
Req.8 User identity

Coming in v1.4.01

Process evidence: merged pull requests, approvals, required checks, branch protection, rulesets and bypasses, sealed per change.

Req.6.5
Change approval
Req.6 Secure software work
Process evidence: every merged pull request is sealed as a change record with its approvals on the final commit, the required checks at merge, who merged it, its signatures and the code verdicts it carried.

Supporting1

Toevan records related evidence, today or in v1.4.0, but the duty is organisational, so it never counts as covered.

Req.12.10
Incident response plan
Req.12 Governance program
Supporting evidence today: a rule records evidence related to this duty. The duty itself is an operational process.

Planned15

Can be evidenced from code or GitHub. The rule or mapping is not built yet.

Req.1.2
Network configuration
Req.1 Network boundary rules
Req.1.4
Trusted network edges
Req.1 Network boundary rules
Req.2.2
System hardening settings
Req.2 Hardened system settings
Req.3.2
Data retention limits
Req.3 Stored data safeguards
Req.3.4
Card number masking
Req.3 Stored data safeguards
Req.6.4
Web attack defenses
Req.6 Secure software work
Req.8.2
Account lifecycle
Req.8 User identity
Req.8.3
Strong authentication
Req.8 User identity
Req.8.4
Second factor use
Req.8 User identity
Req.8.5
Second factor settings
Req.8 User identity
Req.10.2
Audit log content
Req.10 Audit logging
Req.10.3
Log tamper protection
Req.10 Audit logging
Req.10.5
Log retention
Req.10 Audit logging
Req.11.3
Recurring scans
Req.11 Security testing
Req.11.6
Payment page integrity
Req.11 Security testing

Your organisation36

Policy, people, physical security, contracts, regulatory procedure, operations or external audit. Your organisation evidences these.

Show all 36 controls

Req.1 Network boundary rules

Req.1.1Network policy recordorganisational policy
Req.1.5Endpoint bridging policyorganisational policy

Req.2 Hardened system settings

Req.2.1Hardening policy recordorganisational policy
Req.2.3Wireless reviewan operational process

Req.3 Stored data safeguards

Req.3.1Data protection policyorganisational policy
Req.3.7Key lifecycle processan operational process

Req.4 Transit encryption

Req.4.1Transit policy recordorganisational policy

Req.5 Malware defense

Req.5.1Malware policy recordorganisational policy
Req.5.2Endpoint malware defensean operational process
Req.5.3Malware update monitoringan operational process
Req.5.4Phishing defensesan operational process

Req.6 Secure software work

Req.6.1Development policy recordorganisational policy

Req.7 Access limits

Req.7.1Access policy recordorganisational policy

Req.8 User identity

Req.8.1Sign in policyorganisational policy

Req.9 Physical site access

Req.9.1Physical policy recordorganisational policy
Req.9.2Facility entry controlsphysical security
Req.9.3Visitor access recordsphysical security
Req.9.4Media handling rulesphysical security
Req.9.5Terminal tamper reviewphysical security

Req.10 Audit logging

Req.10.1Logging policy recordorganisational policy
Req.10.4Routine log reviewan operational process
Req.10.6Clock synchronizationan operational process
Req.10.7Failure detection processan operational process

Req.11 Security testing

Req.11.1Testing policy recordorganisational policy
Req.11.2Rogue wireless reviewan operational process
Req.11.4Penetration testingan external assessment
Req.11.5Intrusion detection processan operational process

Req.12 Governance program

Req.12.1Security policy programorganisational policy
Req.12.2Acceptable use rulesorganisational policy
Req.12.3Targeted risk revieworganisational policy
Req.12.4Compliance oversightorganisational policy
Req.12.5Scope definition recordorganisational policy
Req.12.6Awareness trainingpeople and HR
Req.12.7Staff screeningpeople and HR
Req.12.8Provider contractscontracts and vendors
Req.12.9Provider support dutiescontracts and vendors

Using it in an audit

Take the population from the change records (from v1.4.0)
Every merge into a protected branch and every direct push in the period, captured from GitHub as it happened, is a sealed record you can export for sampling. You can re-perform the default branch’s population from git history; designated production branches are planned for v1.4.1.
Read the code evidence for the period
Each pull request carries sealed code results against the blueprint’s rules, pinned to the commit and the rule-set version in force.
Test a sample
For each sampled record, check its results, then verify its signature and its place in the chain offline.
$ toevan audit verify --path evidence-clone --pub-key toevan.pub

How each fact was obtained

Every fact in a record and a report carries one of six labels, so your auditor knows how far to rely on it.

Recomputed: Toevan computed it from the code or git history itself.; Re-perform it from the same inputs and get the same result.
Reported + sealed: GitHub reported it; Toevan captured it at the event and signed it.; Rely on it as far as you rely on GitHub. Any later change is detectable.
Declared + sealed: The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.; See who declared what, when, and every later change.
Toevan record, not sealed: Held in Toevan’s database but not sealed in the ledger, such as a waiver today. Nothing protects it by a signature.; Treat it as Toevan’s statement, and ask the organisation for the approval behind it.
Consumed: Taken from another system’s signed record, such as build provenance, and linked by commit or digest. Planned.; Check the original record independently.
Not captured: No reliable source was available. Toevan does not infer it.; Obtain it from the organisation by other means.

See it in a report

The sample change evidence report shows the evidence as your auditor receives it, with every fact labelled.

Open the sample report

Test the mapping on a real audit.

Bring one repository and an upcoming audit. We’ll set up the blueprint and walk your auditor through verification.

Book an audit pilot See a sample report