Skip to content
toevan
Sign inBook an audit pilot
Open menuClose menu
Book an audit pilot

Control map · 2022, Annex A

ISO/IEC 27001

Code evidence for Annex A controls from secrets handling to cryptography, and change, code-access and settings evidence from every merge.

Book an audit pilotSee a sample report
ISO/IEC 27001 · 2022, Annex A26 controls in scope · as mapped in v1.4.1
  • Code 9
  • Process 6
  • Planned 11

Code evidence

9controls checked on every pull request

Live (process)

6from merges, approvals, rule changes, and deployments and releases recorded by GitHub

Planned

11can be evidenced from code or GitHub; not built yet

Organisation-level controls

Policies, people, vendors, physical security and the like, listed below.Toevan gives supporting evidence for 2 of these.Managed by your organisation’s workflows

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.

The ISO/IEC 27001 blueprint gives code evidence for Annex A controls from secrets handling to cryptography. Process evidence from every merge 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.

Code evidence9

Sealed on every pull request. Always partial: the control also asks for things outside code. Rules in the ISO/IEC 27001 blueprint check part of each on every pull request.

  • A.5.15Access rulesA.5 Organisation themes
  • A.5.17Secrets handlingA.5 Organisation themes
  • A.8.2Powerful account limitsA.8 Technology themes
  • A.8.3Data read limitsA.8 Technology themes
  • A.8.8Software flaw fixingA.8 Technology themes
  • A.8.12Data leak pathsA.8 Technology themes
  • A.8.20Network safeguardsA.8 Technology themes
  • A.8.22Network zonesA.8 Technology themes
  • A.8.24Encryption and keysA.8 Technology themes

Live (process)6

Merged pull requests, approvals, required checks, branch protection, rulesets and bypasses, and deployments and releases recorded by GitHub, each sealed.

  • A.8.4Code access limitsA.8 Technology themesProcess evidence: branch protection, rulesets and every bypass of a protected branch, sealed as control changes.
  • A.8.9Approved settingsA.8 Technology themesProcess evidence: changes to repository rulesets and branch protection, sealed with their before and after state.
  • A.8.25Safe build stagesA.8 Technology themesProcess evidence: the reviews and required checks at merge show the development process ran on each change.
  • A.8.29Release security testsA.8 Technology themesProcess evidence: the required security checks that passed at merge, per change.
  • A.8.31Test live splitA.8 Technology themesProcess evidence: A production deployment of a commit that had an earlier successful deployment to another environment. This does not show what was tested there, or the separation of access and data between environments.
  • A.8.32Change approvalsA.8 Technology themesProcess 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 data
Pull request  payments-api #1921 · Add tenant check to refund handlerReported + sealed
Approvals  9d07…e3a4, c58f…71d0 · both on final commit e81b2d0Reported + sealed
Independent of author  Yes, by GitHub account idRecomputed
Required checks  ci/test ✓ · ci/lint ✓ · toevan/gate ✓Reported + sealed
Rules in force  main-protection: 2 approvals, required checks, signed commitsReported + sealed

Supporting2

Toevan records related evidence, but the duty is organisational, so it never counts as covered.

  • A.5.3Separate dutiesA.5 Organisation themesSeparation of duties per change: the author against the approvers, computed from GitHub account ids. The wider duty stays organisational.
  • A.5.32Software rights recordsA.5 Organisation themesSupporting evidence: a rule records evidence related to this duty. The duty itself is regulatory procedure.

Planned11

Can be evidenced from code or GitHub. No rule checks these yet; each is planned, and none counts as evidence today.

  • A.5.16Identity lifecycleA.5 Organisation themes
  • A.5.18Permissions reviewA.5 Organisation themes
  • A.8.5Sign in strengthA.8 Technology themes
  • A.8.10Data deletionA.8 Technology themes
  • A.8.11Sensitive data maskingA.8 Technology themes
  • A.8.13Backup copiesA.8 Technology themes
  • A.8.15Activity recordingA.8 Technology themes
  • A.8.26App security demandsA.8 Technology themes
  • A.8.27Secure design habitsA.8 Technology themes
  • A.8.28Secure coding habitsA.8 Technology themes
  • A.8.33Test data careA.8 Technology themes

Organisation-level controls

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

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

  1. 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.

  2. 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.

  3. 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.

    The three steps, with the exact commands

How each fact was obtained6 labels
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.
A.8.4Change approvalsTest sheet · example data
Population148 changes: 146 merged pull requests and 2 direct pushes
Recomputed listed from git history and matched to the sealed records
Sample25 drawn by the auditor, each a sealed record
ApprovalsReported + sealed from GitHub at merge, independent of the author
ExceptionsNo PR 2 direct pushes on 19 SepGap review requirement off for 29 minutesBoth are in the record.
Signatures25 / 25 ✓ Verified OK
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 pilotSee a sample report
  • One repository, one framework
  • Evidence from the first pull request
  • Verifiable without a Toevan account