Skip to content
steelabs

Template

Security questionnaire evidence library

Map a buyer’s question to an owned control, dated evidence and an honest limitation. Includes a sample finding, retest record and engagement boundaries.

Download editable Markdown

How to use this

Useful for: Product teams answering procurement questions without unsupported security claims.

  1. Translate each question into a specific control and scope. Confirm what the buyer is asking before equating an application assessment with an organisation-wide certification.

  2. Identify evidence that can be shared and who can approve it. Keep secrets, customer records and exploit details in restricted storage; an index can point to that material without reproducing it.

  3. Attach a date, system boundary and owner to each answer. A report about a previous build or a different service should not silently become evidence for the current product.

  4. Separate implemented controls, work in progress and gaps. An explicit limitation is more useful than an unconditional yes that the delivery team cannot substantiate.

Scope and limitations: Illustrative evidence structures only. No security certification, procurement approval or actual client finding is represented by the sample.

Document preview

# Security evidence library

## Answer register
| Buyer question | Control / scope | Answer and limitation | Evidence / date | Owner | Sharing approval |
| --- | --- | --- | --- | --- | --- |
| How are permissions tested? | Named application and build | Describe the performed checks and exclusions | Access matrix and assessment | | |
| How are vulnerabilities handled? | Dependency and incident process | Describe triage, ownership and review dates | Triage record and procedure | | |

## Evidence record
- Document title, version and review date:
- Systems and builds covered:
- Methodology and agreed testing boundaries:
- Findings, remediation and retest references:
- Exclusions and residual uncertainty:
- Distribution classification and authorised recipients:

## Rules of engagement
- Written authorisation and systems in scope:
- Test window and points of contact:
- Permitted techniques and stop conditions:
- Synthetic accounts and protected data:
- Incident escalation and evidence handling:
- Deliverable, remediation discussion and retest scope:

## Finding example — fictional
Observation: a member of organisation A can read a synthetic record belonging to organisation B through one API operation.
Expected: the operation enforces the agreed organisation boundary.
Evidence: record request identifiers and a redacted response in the private issue; do not publish credentials or the exploitable endpoint.
Impact: unauthorised disclosure within the tested operation. The example does not establish the reach of other operations.
Remediation: enforce the object-level policy at the server boundary and add positive and negative regression checks.

## Retest example — fictional
Candidate: demo-43; environment: isolated staging.
Performed: repeat the original refused-access request, test an authorised caller and check the related operation named in the retest scope.
Observed: the original request is denied without object data; the authorised request still succeeds.
Limit: no conclusion about endpoints outside this retest. Attach observed responses and name the reviewer before closing the issue.

An assessment report and an organisation certification answer different questions. Link the exact evidence instead of translating one into the other.

Read alongside this worksheet

Get help applying itAll resources