Control map · 2022, Annex A

ISO/IEC 27001

16 of 26 ISO/IEC 27001 controls code can evidence, with v1.4.0, plus 2 supporting

Code evidence for eleven Annex A controls today; change, code-access and settings evidence in v1.4.0.

Live11
Coming in v1.4.05
Supporting2
Planned10
Your organisation65

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

A certification or surveillance audit asks for evidence that Annex A controls are implemented and operating. For engineering, that means change handling and secure development.

Today the ISO/IEC 27001 blueprint gives code evidence for eleven controls, from secrets handling to secure coding. From v1.4.0, process evidence adds change approvals, safe build stages, release security tests, code access limits and approved settings. Organisational, people and physical controls stay with your ISMS.

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.

Live11

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

A.5.15
Access rules
A.5 Organisation themes
A.5.17
Secrets handling
A.5 Organisation themes
A.8.2
Powerful account limits
A.8 Technology themes
A.8.3
Data read limits
A.8 Technology themes
A.8.5
Sign in strength
A.8 Technology themes
A.8.8
Software flaw fixing
A.8 Technology themes
A.8.12
Data leak paths
A.8 Technology themes
A.8.20
Network safeguards
A.8 Technology themes
A.8.22
Network zones
A.8 Technology themes
A.8.24
Encryption and keys
A.8 Technology themes
A.8.28
Secure coding habits
A.8 Technology themes

Coming in v1.4.05

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

A.8.4
Code access limits
A.8 Technology themes
Process evidence: branch protection, rulesets and every bypass of a protected branch, sealed as control changes.
A.8.9
Approved settings
A.8 Technology themes
Process evidence: changes to repository rulesets and branch protection, sealed with their before and after state.
A.8.25
Safe build stages
A.8 Technology themes
Process evidence: the reviews and required checks at merge show the development process ran on each change.
A.8.29
Release security tests
A.8 Technology themes
Process evidence: the required security checks that passed at merge, per change.
A.8.32
Change approvals
A.8 Technology themes
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.

Supporting2

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

A.5.3
Separate dutiesComing in v1.4.0
A.5 Organisation themes
Separation of duties per change: the author against the approvers, computed from GitHub account ids. The wider duty stays organisational.
A.5.32
Software rights records
A.5 Organisation themes
Supporting evidence today: a rule records evidence related to this duty. The duty itself is regulatory procedure.

Planned10

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

A.5.16
Identity lifecycle
A.5 Organisation themes
A.5.18
Permissions review
A.5 Organisation themes
A.8.10
Data deletion
A.8 Technology themes
A.8.11
Sensitive data masking
A.8 Technology themes
A.8.13
Backup copies
A.8 Technology themes
A.8.15
Activity recording
A.8 Technology themes
A.8.26
App security demands
A.8 Technology themes
A.8.27
Secure design habits
A.8 Technology themes
A.8.31
Test live split
A.8 Technology themes
A.8.33
Test data care
A.8 Technology themes

Your organisation65

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

Show all 65 controls

A.5 Organisation themes

A.5.1Written policy setorganisational policy
A.5.2Security role ownersorganisational policy
A.5.4Leadership backingorganisational policy
A.5.5Authority contactsorganisational policy
A.5.6Expert group contactsorganisational policy
A.5.7Attacker news trackingan operational process
A.5.8Project security stepsorganisational policy
A.5.9Owned asset listorganisational policy
A.5.10Asset use rulesorganisational policy
A.5.11Assets handed backorganisational policy
A.5.12Sensitivity sortingorganisational policy
A.5.13Sensitivity markingorganisational policy
A.5.14Data transfer rulesorganisational policy
A.5.19Vendor security demandscontracts and vendors
A.5.20Vendor agreement clausescontracts and vendors
A.5.21Supply chain controlscontracts and vendors
A.5.22Vendor service reviewcontracts and vendors
A.5.23Cloud use rulesorganisational policy
A.5.24Incident readinessan operational process
A.5.25Event severity sortingan operational process
A.5.26Incident response stepsan operational process
A.5.27Incident learningan operational process
A.5.28Incident evidence collectionan operational process
A.5.29Outage security plansan operational process
A.5.30Recovery readinessan operational process
A.5.31Legal duty trackingregulatory procedure
A.5.33Records safekeepingregulatory procedure
A.5.34Privacy dutiesregulatory procedure
A.5.35Independent reviewan external assessment
A.5.36Policy compliance reviewan external assessment
A.5.37Written operating stepsorganisational policy

A.6 People themes

A.6.1Hiring background screeningpeople and HR
A.6.2Written security dutiespeople and HR
A.6.3Security awareness trainingpeople and HR
A.6.4Rule breaking consequencespeople and HR
A.6.5Duties after leavingpeople and HR
A.6.6Promises about secretspeople and HR
A.6.7Remote work safeguardsorganisational policy
A.6.8Staff problem reportingan operational process

A.7 Physical themes

A.7.1Secure site boundariesphysical security
A.7.2Site entry controlsphysical security
A.7.3Locked roomsphysical security
A.7.4Premises watchingphysical security
A.7.5Fire flood protectionphysical security
A.7.6Secure area rulesphysical security
A.7.7Tidy desksphysical security
A.7.8Equipment sitingphysical security
A.7.9Away asset safeguardsphysical security
A.7.10Disk drive carephysical security
A.7.11Power failure backupphysical security
A.7.12Cabling protectionphysical security
A.7.13Equipment servicingphysical security
A.7.14Safe equipment wipingphysical security

A.8 Technology themes

A.8.1User device protectionan operational process
A.8.6Capacity planningan operational process
A.8.7Malware defensean operational process
A.8.14Spare capacityan operational process
A.8.16Unusual behavior watchingan operational process
A.8.17Clock matchingan operational process
A.8.18Utility program limitsan operational process
A.8.19Live software approvalan operational process
A.8.21Network service rulesan operational process
A.8.23Web traffic filteringan operational process
A.8.30Outside developer oversightcontracts and vendors
A.8.34Audit safeguardsan external assessment

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