# Enterprise Security Questionnaire Evidence Ledger

Use this ledger to connect each customer question to a scoped statement, current evidence, accountable approval and review date.

It is an educational working template, not a security certification, legal opinion, contractual interpretation or guarantee that a customer will approve the service.

## Handling rule

Do not put credentials, tokens, private keys, personal-data exports, customer secrets, raw vulnerability proof or unredacted production screenshots in this file. Store sensitive evidence in an approved controlled location and reference its record ID or owner.

## 1. Review scope

| Field | Record |
| --- | --- |
| Customer / review ID |  |
| Questionnaire name and version |  |
| Product / service |  |
| Environments |  |
| Features in scope |  |
| Customer data classes |  |
| User and administrator roles |  |
| Integrations / network connection |  |
| Regions / support locations |  |
| Availability and recovery criticality |  |
| Buyer security-review owner |  |
| Vendor response owner |  |
| Submission date |  |
| Contract / security-schedule relationship | `NOT VERIFIED` until reviewed |
| Evidence-sharing method |  |

## 2. Response states

| State | Meaning |
| --- | --- |
| `VERIFIED` | Current evidence supports the exact statement for the stated scope. |
| `PARTIAL` | The control exists, but material boundaries or exceptions remain. |
| `PLANNED` | Approved work has an owner and target, but the control is not implemented today. |
| `NOT APPLICABLE` | The customer scenario is genuinely outside the control, with a written rationale. |
| `NOT VERIFIED` | Evidence is missing, contradictory or not yet reviewed. |
| `RESTRICTED EVIDENCE` | The claim is verified, but supporting detail needs controlled review. |

## 3. Evidence levels

| Level | Examples | What it can support |
| --- | --- | --- |
| Policy / design | approved policy, standard, procedure, architecture decision | Intended requirement and control design |
| Implementation | configuration export, code rule, infrastructure definition, data-flow map | Implemented state for the named scope |
| Operation | access review, restore record, alert test, incident exercise, remediation trace | Observed operation at a date or over a period |
| Independent assurance | scoped SOC report, ISO/IEC certificate, assessment, penetration-test report | Independent evidence within the stated system, period, method and limitations |

## 4. Answer and evidence register

Duplicate rows as needed. Keep the exact buyer wording.

| ID | Buyer question | Domain | Exact scope | State | Approved response | Evidence level and controlled pointer | Observation date | Control owner | Limitation / exception | Disclosure class | Approvals | Review / expiry trigger |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Q-001 |  |  |  | `NOT VERIFIED` |  |  |  |  |  | Internal |  |  |
| Q-002 |  |  |  | `NOT VERIFIED` |  |  |  |  |  | Internal |  |  |
| Q-003 |  |  |  | `NOT VERIFIED` |  |  |  |  |  | Internal |  |  |

Suggested domains: scope/data flow, identity/access, tenant authorization, encryption/key management, logging/auditability, backup/recovery, incident response, secure development/release, dependencies/SBOM, vulnerability management/testing, subprocessors, AI/model providers, privacy/retention/deletion, people/offboarding, policies/governance, assurance/contract commitments.

## 5. Gap and commitment register

Do not convert this table into an affirmative answer until verification is complete.

| Gap ID | Related questions | Confirmed fact or unknown | Customer / business impact | Current limitation or compensating control | Remediation scope | Owner | Target verification date | Evidence required to close | Buyer decision / exception status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| G-001 |  |  |  |  |  |  |  |  | `NOT VERIFIED` |

## 6. Assurance artifact register

| Artifact | Entity / system scope | Type / standard / version | Period or validity | Issuer / assessor | Opinion, exceptions or open findings | Distribution rule | Current status and owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |

Terminology guardrails:

- SOC 2 is an examination/report, not a certification.
- ISO/IEC certification is performed by an external certification body, not by ISO.
- NIST does not certify or endorse CSF implementations.
- An assurance artifact supports only its stated entity, system, period, criteria and limitations.

## 7. Controlled disclosure log

| Evidence ID | Classification | Recipient and purpose | Redaction / minimum version | Access method | Approver | Granted | Expires / revoked | Access or download evidence |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| E-001 |  |  |  |  |  |  |  |  |

## 8. Submission approvals

| Role | Confirms | Owner | Status / date |
| --- | --- | --- | --- |
| Engineering / operations | Technical scope and current evidence |  | `NOT VERIFIED` |
| Security / privacy | Control meaning, risk, data handling and disclosure |  | `NOT VERIFIED` |
| Legal / commercial | Contract, notification, privacy and assurance wording |  | `NOT VERIFIED` |
| Business owner | Gaps, priorities and proposed commitments |  | `NOT VERIFIED` |

## 9. Consistency check

- [ ] Questionnaire matches the current security overview or trust material.
- [ ] DPA and subprocessor register match the data-flow evidence.
- [ ] MSA, security schedule and SLA do not contain a broader contradictory promise.
- [ ] SOC/ISO/assessment language names the correct type, scope and period.
- [ ] Planned work is not described as implemented.
- [ ] `NOT APPLICABLE` answers include a scoped rationale.
- [ ] Restricted evidence uses approved access, redaction and expiry.
- [ ] Buyer-specific answers are marked so they are not reused automatically.
- [ ] Every material answer has an owner and review trigger.

## 10. Post-submission record

| Field | Record |
| --- | --- |
| Exact submitted file / digest |  |
| Submission channel and date |  |
| Buyer follow-up owner |  |
| Buyer exceptions / conditions |  |
| Contract language changed | `NOT VERIFIED` |
| Remediation accepted by business owner | `NOT VERIFIED` |
| Answer-library update owner |  |
| Next review date / trigger |  |

Source guide: https://www.buildwithh.com/blog/security-questionnaire-inherited-software