One set of security records for customers, auditors and regulators
Customers, certification auditors, regulators, insurers and buyers each ask about a company's security in their own words. This chapter shows that they ask for the same small set of records, such as an access review or a signed software release. A company that produces these records as part of its normal work can answer each new request from what it already has.
- Leading security at two startups in a row, both acquired about two years after I joined
- ACME, the company this series follows
- One set of security records for customers, auditors and regulators (you are here)
- Proactive, application and detective security in a growing company
ACME, the made-up company this series follows, has twelve people and sells an energy dashboard to shops and offices. A retail chain wants it for its stores and has sent a security questionnaire, and a property manager has asked whether ACME is certified to ISO 27001.
Controls, records and frameworks
This series uses three words with a fixed meaning.
- Control
- Something the company does to reduce a risk. Checking every quarter who can sign in to the production systems is a control. So is the rule that a second developer approves each change before it is released.
- Record
- The proof that a control took place. For the access check, the record is the list of people with access, with the date, the name of the person who checked it and the changes made as a result. For the approval of changes, the record is the approved pull request, which the code hosting service keeps.
- Framework
- A list of controls that someone requires. ISO 27001, SOC 2, NIS2 and the Cyber Resilience Act are frameworks in this sense, and so is the questionnaire a customer sends. They use different wording and numbering, and someone checks all of them by looking at records.
The people who ask
Over the life of a company like ACME, these readers ask about its security. They arrive at different times and for different reasons.
- A customer's procurement or security team sends a questionnaire before it buys. Its own customers and auditors ask it the same questions, so it passes them on to its suppliers.
- An ISO 27001 auditor from a certification body checks the company's management system and its controls before issuing a certificate, and returns every year.
- A SOC 2 auditor from an audit firm tests the controls over a period of months and writes a report. Customers in the United States often ask for it.
- A customer covered by NIS2, the EU directive for essential and important organisations, has to manage the security of its suppliers, and it adds requirements to the contract.
- GDPR applies to every company that handles personal data, and the data protection authority can ask how that data is protected.
- The Cyber Resilience Act applies to companies that sell products with software in the EU. A market surveillance authority can ask for a product's technical documentation.
- An insurer asks before it covers cyber risks.
- A buyer of the company runs due diligence before the sale.
First example: the access review
Every three months, Andrew, ACME's CTO, exports the list of people who can sign in to the production systems. He compares it with the list of current staff and their roles, removes access that is no longer needed, and signs and dates the result. It takes him up to a few hours, and the result is one file.
The table lists what each reader asks for and which part of the record answers it.
| Reader | What they ask for | What answers it |
|---|---|---|
| Customer questionnaire | Whether access is reviewed regularly, and who approves it | The latest signed export and its date |
| ISO 27001 auditor | The access rights control in Annex A, which covers granting, reviewing and removing access | The last exports and the policy that sets how often the review happens |
| SOC 2 auditor | The criteria on granting, changing and removing access to systems | Every quarterly export in the audit period |
| NIS2 customer | Access control, which is on the list of measures NIS2 requires of the customer, and how its suppliers handle it | The export and the policy, usually through a supplier questionnaire |
| GDPR | Security of processing, which includes limiting who can reach personal data | The export, as part of showing that access to personal data is limited |
| Acquirer | Who can reach production systems and customer data, and how people who leave lose access | The exports, together with the records of people leaving |
The Cyber Resilience Act does not appear in this table. It covers the security of the product itself, so it asks about access control inside ACME's gateway, and staff access to ACME's own systems is outside its scope.
Second example: a signed release
From its third stage ACME ships a gateway, a program that customers run in their own buildings to read their electricity meters. The build pipeline produces each release, together with an SBOM, a list of every library inside the release, and it signs both with ACME's key. The release page shows the version, the checksums, the signature and the SBOM.
| Reader | What they ask for | What answers it |
|---|---|---|
| Customer | A way to check that the installed software is the one ACME built, and the list of libraries in it | The signature, the checksums and the SBOM |
| Cyber Resilience Act | An SBOM covering at least the top-level dependencies, protection of programs against changes the user did not authorise, and a secure way to distribute updates | The SBOM and the signed release, kept in the product's technical documentation |
| SOC 2 auditor | The change management criterion: changes are authorised, tested and approved before release | The pipeline run that built the release, with the approved changes it contains |
| ISO 27001 auditor | The change management and secure development controls in Annex A | The same pipeline records |
| NIS2 customer | Supply chain security, which includes the quality of each supplier's secure development | The SBOM, the signature and a short description of the pipeline |
| Acquirer | Which open-source licences the product depends on | The SBOM, with the licence of each library |
Records made during the work
Both records come out of work that happens anyway. The access review is an export from the identity provider plus an hour of checking. The signed release takes a few extra steps in a pipeline that already builds the release. Nobody wrote either of them for an auditor.
A company that keeps records this way answers a new questionnaire by finding files it already has, and an audit turns into handing over samples. When documents are written separately for each reader, the work repeats with each one. A document written in the weeks before an audit also describes what should have happened, and experienced auditors and customers notice, because its dates and details do not match what the systems show.
The engineering companion to this chapter shows how ACME's pipeline stores each record with a hash, so that a customer or an auditor can later confirm that it was not changed.
From the field. At Krizo and at Omnio, the record that answered the most readers was the list of every dependency in the product: the Haskell packages at Krizo, and the Rust crates and Python packages at Omnio. Automated tools such as Trivy produced it on every pull request in the build pipeline, together with the scans of the infrastructure code and the Docker images, and we kept the results in storage buckets. The same files answered customers' questionnaires and their security teams, as well as the auditors.
The licence check ran on the same files. We denied licences that we could not legally ship, such as the AGPL, and packages with no licence at all. Where we had bought a commercial licence for a library, the record said so. Depending on its licence, a component was linked dynamically or statically, or ran as a separate service. The scanners still flagged those components, and each one had to be defended in front of an auditor or a customer's security team. Once we explained exactly how a component was used, they accepted it, but every explanation took extra time.
Differences between the readers
The readers overlap a great deal, and some of them also ask for records that only they need.
- A SOC 2 Type II report covers a period, usually six to twelve months, so the auditor asks for records from the whole period. One review done just before the audit does not cover it.
- ISO 27001 asks for the management system itself: a risk assessment, an internal audit and a yearly review by management. These are records about the program, and later chapters cover them.
- GDPR asks for a record of processing activities, which lists the personal data the company holds and the purpose of each.
- The Cyber Resilience Act asks for technical documentation for each product, covered in part 4.
Cost
These are estimates. Depending on the company and how it operates, the real numbers can be higher or lower.
- Setting up
- A few days of a senior person's time to decide which records the company keeps and who produces each one.
- Recurring attention
- Up to a few hours a quarter for the access review. The release records add no time once the pipeline produces them.
- Skill
- Someone who knows the company's systems and has been through at least one audit or large customer review.
- Money
- Storage for the records, a few euros a month at ACME's size.
- Too early
- A webshop at ACME's first stage needs only a few of these records, for backups, updates and administrator accounts (chapter 2.1). The full set becomes worth building when the first business customer asks.
Keeping all of this under control also takes attention, beyond the hours. It can break the concentration needed for product work or for leading new business, and in a small company the same person often does both.
Limits
This chapter shows the idea with two records. The full list of records, and the readers who ask for each one, grows chapter by chapter. The ISO 27001 and SOC 2 entries name controls and criteria from published mappings and audit checklists, and an auditor may ask for more, depending on the scope. Nothing here is legal advice.