Control map · v4.0
PCI DSS
Code evidence for stored and transit card data, secrets, access and secure code, and change approval from every merge.
Code evidence
9requirements checked on every pull requestLive (process)
1from merges, approvals, rule changes, and deployments and releases recorded by GitHubPlanned
16can be evidenced from code or GitHub; not built yetOrganisation-level requirements
Policies, people, vendors, physical security and the like, listed below.Managed by your organisation’s workflowsAssessors test secure software and change control from change tickets, code-review records and scan results.
The PCI DSS blueprint gives code evidence for requirements such as stored-data encryption, transit encryption and service-account secrets. Every merged change carries its approval as a sealed record.
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.
Code evidence9
Sealed on every pull request. Always partial: the control also asks for things outside code. Rules in the PCI DSS blueprint check part of each on every pull request.
Req.1.3Inbound traffic limitsReq.1 Network boundary rulesReq.3.3Authentication secrets retentionReq.3 Stored data safeguardsReq.3.5Stored data encryptionReq.3 Stored data safeguardsReq.3.6Key protectionReq.3 Stored data safeguardsReq.4.2Transit encryptionReq.4 Transit encryptionReq.6.3Vulnerability scanningReq.6 Secure software workReq.7.2Role access rightsReq.7 Access limitsReq.7.3System access limitsReq.7 Access limitsReq.8.6Service account secretsReq.8 User identity
Live (process)1
Merged pull requests, approvals, required checks, branch protection, rulesets and bypasses, and deployments and releases recorded by GitHub, each sealed.
Req.6.5Change approvalReq.6 Secure software workProcess evidence: every pull request merged into the default branch 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.
Change record rec_5b81d4e
example dataPlanned16
Can be evidenced from code or GitHub. No rule checks these yet; each is planned, and none counts as evidence today.
Req.1.2Network configurationReq.1 Network boundary rulesReq.1.4Trusted network edgesReq.1 Network boundary rulesReq.2.2System hardening settingsReq.2 Hardened system settingsReq.3.2Data retention limitsReq.3 Stored data safeguardsReq.3.4Card number maskingReq.3 Stored data safeguardsReq.6.2Secure code habitsReq.6 Secure software workReq.6.4Web attack defensesReq.6 Secure software workReq.8.2Account lifecycleReq.8 User identityReq.8.3Strong authenticationReq.8 User identityReq.8.4Second factor useReq.8 User identityReq.8.5Second factor settingsReq.8 User identityReq.10.2Audit log contentReq.10 Audit loggingReq.10.3Log tamper protectionReq.10 Audit loggingReq.10.5Log retentionReq.10 Audit loggingReq.11.3Recurring scansReq.11 Security testingReq.11.6Payment page integrityReq.11 Security testing
Organisation-level requirements
Organisation-level controls (policies, people, vendors, physical security and the like) stay with your organisation’s own process; Toevan does not cover them.
Show the list
Req.1 Network boundary rules
Req.2 Hardened system settings
Req.3 Stored data safeguards
Req.4 Transit encryption
Req.5 Malware defense
Req.6 Secure software work
Req.7 Access limits
Req.8 User identity
Req.9 Physical site access
Req.10 Audit logging
Req.11 Security testing
Req.12 Governance program
Using it in an audit
- Take the population from the change records
Every pull request merged into the default branch and every push to a protected branch that no merged pull request explains, 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.
- 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 it offline against the published key with openssl and the shell: get the evidence, confirm the key, check the record. To replay the whole chain, Toevan provides the toevan command on request; it is not yet public.
- Recomputed
- Toevan computed it from the code or git history itself.
- Reported + sealed
- GitHub reported it; Toevan captured it at the event and signed it.
- Declared + sealed
- The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.
- 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.
- Consumed
- Taken from GitHub’s deployment and release records and linked by commit or digest.
- Not captured
- No reliable source was available. Toevan does not infer it.
Recomputed listed from git history and matched to the sealed records
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.
- One repository, one framework
- Evidence from the first pull request
- Verifiable without a Toevan account