A security questionnaire is not answered from memory or from prose. It is answered from four kinds of record: whether the control is in place, what governs it, what shows it operated, and what shows it still does. If you run an ISO 27001 management system you already hold all four. The work is knowing which control each question is about, and the map below does that for the thirty topics that make up nearly every questionnaire a European company receives.
The map is ours and it is published in full. It was written from the questions that recur across CAIQ, SIG Lite, VSA and the home-grown spreadsheets, which between them are where almost every questionnaire comes from. Use it without us.
Why questionnaires and audits ask different questions
A customer's questionnaire asks what that customer cares about. An ISO 27001 audit asks about all 93 Annex A controls. The overlap is large but the framing is different: a questionnaire says "do you enforce MFA for all users", the standard says A.8.5, logging in securely. Nobody who wrote the questionnaire was thinking in control numbers, and nobody who built the ISMS was thinking in the customer's words.
That gap is where the hours go. The person answering opens last quarter's spreadsheet, searches for a similar wording, pastes, and adjusts. The answer is usually right and rarely checkable, because it carries no date and cites no record. Six months later the next questionnaire arrives and the exercise repeats.
The fix is to translate each question into the control it is about, then answer from the records the ISMS keeps for that control. Once you do that, the answer writes itself, it carries dates, and it is the same answer the auditor will see.
The four records that answer any question
Read a questionnaire the way a security reviewer reads your answers, in this order:
- Is the control in place? The Statement of Applicability says so, for every one of the 93 controls: applicable or excluded, and if applicable, implemented, in progress or not started. This is the sentence that opens the answer.
- What governs it? An approved policy, with a version number, an approval date and the name of the approver. A policy that exists but was never approved is not governance, and an auditor treats it as a finding. So should you.
- What shows it operated? An evidence record with a collection date and, where it applies, an expiry. A penetration test report from eighteen months ago is a record that the control operated once, not that it operates.
- What shows it still does? A check against the live system, with the date it was last run: MFA enforced in your identity provider, encryption on in your cloud account, no management ports open to the internet.
An answer built from those four sentences is one the customer's security team can check against the next one, because every fact in it has a date. That property is worth more than the wording.
The map
Thirty topics, the Annex A controls each one is about, and the control titles as we phrase them. Where a question spans two topics, both apply.
| What they ask about | Controls | What those controls cover |
|---|---|---|
| MFA, single sign-on, password rules | A.8.5, A.5.17 | Logging in securely; handling passwords, keys and other secrets |
| Encryption at rest and in transit, key management | A.8.24 | Using encryption properly and managing keys |
| Backups and restore testing | A.8.13 | Backing data up and proving restores work |
| Business continuity, disaster recovery, RTO and RPO | A.5.29, A.5.30, A.8.14 | Holding security together during a crisis; keeping technology running through disruption; spare capacity so a failure is survivable |
| Penetration testing, vulnerability management, patching | A.8.8 | Finding and fixing known weaknesses |
| Incident response, breach notification | A.5.24, A.5.26, A.6.8 | Being ready before an incident happens; acting on an incident once it is declared; making it easy for staff to report problems |
| Vendors, subprocessors, third parties | A.5.19, A.5.20, A.5.21, A.5.23 | Managing the risk that suppliers bring; putting security terms into supplier contracts; security through the technology supply chain; using cloud services safely |
| Background checks | A.6.1 | Background checks before hiring |
| Security training, phishing simulation | A.6.3 | Training people to work securely |
| Logging, monitoring, SIEM, alerting | A.8.15, A.8.16 | Recording what happened on your systems; watching systems for suspicious behaviour |
| Access control, least privilege, joiners and leavers, admin access | A.5.15, A.5.18, A.8.2 | Deciding who may reach which systems and data; granting, reviewing and revoking permissions; restricting administrator access |
| Retention, deletion, disposal | A.5.33, A.8.10 | Keeping records safe for as long as required; deleting data you no longer need |
| Security policy, the management system itself | A.5.1 | Written security policies, approved and kept current |
| Classification and labelling | A.5.12, A.5.13 | Grading information by how sensitive it is; marking information with its sensitivity |
| Asset inventory | A.5.9 | Knowing what information and equipment you hold |
| Endpoints, MDM, disk encryption, BYOD | A.8.1, A.6.7 | Securing laptops, phones and desktops; working securely away from the office |
| Malware, antivirus, EDR | A.8.7 | Defending against malware |
| Secure development, code review, change management, CI/CD | A.8.25, A.8.29, A.8.32 | Security throughout how software gets built; testing security before anything ships; controlling changes to live systems |
| Data centres, physical access, offices | A.7.1, A.7.2, A.7.4 | Defining the physical boundary you protect; controlling who gets through the door; watching the premises for intruders |
| Privacy, GDPR, data processing agreement | A.5.34 | Protecting personal data |
| Remote work | A.6.7 | Working securely away from the office |
| Network segmentation, firewalls, VPN | A.8.20, A.8.22 | Securing the network itself; keeping networks separated from each other |
| Cloud provider, hosting region, data residency | A.5.23 | Using cloud services safely |
| Threat intelligence | A.5.7 | Gathering and acting on threat information |
| Legal, regulatory and contractual obligations | A.5.31 | Knowing the laws and contracts that bind you |
| Risk assessment and risk treatment | A.5.1, A.8.8 | Written security policies, approved and kept current; finding and fixing known weaknesses. The risk process itself is clause 6.1 of the standard, not an Annex A control |
| Secrets, API keys, vaults | A.8.5, A.8.24 | Logging in securely; using encryption properly and managing keys |
| Capacity, uptime, SLAs | A.8.6, A.5.30 | Having enough capacity to keep running; keeping technology running through disruption |
| Configuration baselines, hardening | A.8.9 | Keeping systems configured the way you intended |
| Test data and test environments | A.8.33, A.8.31 | Using safe data when testing; keeping build, test and live environments apart |
Two things the map is not. It is a vocabulary, not a legal mapping: SIG and CAIQ have their own control identifiers, and a formal crosswalk to them is a different document. And it is capped by design. A question that matches nine controls has not been understood, so match the two to four it is really about and answer those.
The question about certification
"Are you ISO 27001 certified?" is a question about the system as a whole, not about a control, and it has exactly two honest answers.
If you hold a certificate: the standard, the certification body, the certificate number and the expiry date. The customer will look it up, so the answer should let them.
If you do not: say so, then say what is true. "An ISO/IEC 27001 management system is in operation, with 71 of 84 applicable Annex A controls implemented, and certification by an accredited body is planned for March." That is a stronger answer than most procurement teams expect from an uncertified vendor, and it is checkable. What it must never do is blur the line. Certificates come from an accredited certification body, and ISO/IEC 17021-1 requires that body to be independent of whoever helped you prepare. A vendor that offers both is the thing to check.
What to say when the record says "in progress"
Say in progress.
A questionnaire answer is a representation to a customer, often under a contract that makes misrepresentation expensive, and the only defensible answer is the one your records support. If the Statement of Applicability says A.8.16 is in progress, the draft says the control is being implemented and is not yet complete, and the person sending it decides what else to add with the record in front of them.
The same applies to the three other ways an answer quietly overclaims:
- A control excluded with no justification. In a questionnaire that reads as evasion; in your SoA it is a finding at Stage 1. Write the reason once and both problems go away.
- Evidence past its expiry. An answer that cites a penetration test should cite its date, and if the date is old the answer should say a new one is scheduled, or drop it.
- A failing check. If your identity provider reports that MFA is not enforced for every user, the answer cannot say it is. Fix it first, or say so.
The customer's security team is not looking for perfection. They are looking for the vendor whose answers they can trust in eighteen months, and the tell is whether the answers carried dates the first time.
The part that compounds
The fortieth questionnaire is mostly the first thirty-nine. "Do you enforce MFA?" and "Is MFA enforced for all user accounts?" are the same question, and a confirmed answer to one is the draft of the other.
Keep every confirmed answer with the question it answered, and match new questions against them by meaning rather than exact wording. Then reconfirm before reuse, every time, because what was true in March may not be in September. A reused answer that nobody looked at is how a company ends up asserting a control it retired.
What software should and should not do here
The tools in this category increasingly draft answers with a language model, and the results are only as trustworthy as the rule they run under. The rule that holds up is: the record is the source, the model is a typist, and a person confirms. A model may rephrase a draft composed from your SoA, policies, evidence and checks into the customer's question form. It may not add a fact, however plausible, and it may not answer from what "most companies" do. A confident, fluent answer that no record supports is the most expensive sentence a compliance tool can produce.
If the ISMS has nothing on a question, the right output is a blank and a note saying so. The person answers it from knowledge, then records the control, policy or evidence it relied on, so the next questionnaire can reuse it. That is how the record grows to match what customers actually ask.
That rule is how StandardOS drafts questionnaire answers: from the organization's own records, cited by name and date, confirmed by a person, and reused next time. If you sell into Europe, the questionnaire is often the first place a buyer checks for ISO 27001 at all: it appears in 3,408 EU tender notices over the last year, against 104 for SOC 2.