​

Traceability Audit Prep

Run this checklist the week before the auditor arrives. It catches the issues that typically delay an audit by days — incomplete matrices, stale connectors, unverifiable hash chains, access-control gaps — when fixing them before the auditor sees them takes hours. Applies whether the auditor is external (notified body, certification body) or internal (QA leadership, customer compliance team).

​

When to run

​

The checklist

​

1. Matrix completeness

• Open the traceability matrix for the release under audit.
• Filter to uncovered requirements. Each one is a potential audit finding.
• For each uncovered requirement: either add a confirming test or document as acknowledged gap with rationale.
• Filter to failing tests on the release. Each is a potential audit blocker.
• Filter to requirements with only failed tests confirming them. These count as uncovered for audit purposes — close them.

​

2. Acknowledged gap rationale

• List every acknowledged gap in the release.
• Confirm each has documented rationale visible in the requirement record.
• Confirm the rationale is defensible to the auditor — “we’ll get to it” is not a rationale; “this clause does not apply to our product class because…” is.
• Get sign-off from the safety engineer or compliance lead on safety-typed acknowledged gaps.

​

3. Requirement snapshotting

• Confirm the release is in verified or shipped state (snapshots are taken at verified transition).
• Confirm every requirement in the snapshot has a derives_from referencing a pinned standard (where applicable to your project — purely internal requirements may legitimately have an empty derives_from).
• Confirm derives_from references the correct edition of each standard — not an obsolete one.

​

4. Evidence-pack integrity

• Generate the evidence pack for the release if not already generated:
  rbtk test evidence-pack --release <tag> --format pdf,zip,reqif
  
• Verify the hash chain:
  rbtk evidence verify <pack_id>
  rbtk evidence verify-chain --project <org>/<project>
  
  Both should pass with no errors. A verification failure must be resolved before the audit.
• Open the PDF and skim. The cover page, table of contents, requirements section, and disclaimer should all render correctly. Customised templates (Enterprise) should render with the correct branding.
• Confirm any MCAPs the auditor might want are either in hot storage (90-day window) or that you have time to restore from Glacier (Standard: 9–12 hours; Bulk: 48 hours — see Archive).

​

5. Connector configuration review

• List active BYO connectors for the project.
• Confirm each connector last ran successfully within the last 24 hours. A connector that broke after the most recent verification leaves stale data in the pack.
• For Polarion / Jama / codeBeamer / DOORS connectors: confirm the requirement-snapshot import matches the version in the upstream system at release-cut time.
• For LDRA / Polyspace / Coverity: confirm SARIF output is current and present in the pack.

​

6. Standards-feed posture

• List pinned standards and check for open amendment alerts not yet triaged.
• For any open amendment: either complete triage before the audit, or document the open alert with a triage plan and target date.
• Auditors often check the feed posture as a signal of overall hygiene; un-triaged amendments are a soft warning sign.

​

7. Access controls

• Review project member list. Remove members who no longer need access.
• Review read-only share links for the release. Revoke any that have served their purpose.
• Generate a fresh read-only share link for the auditor with a sensible expiry (default 90 days; extend to 180 if your audit cycle is slow).
• Test the share link from a fresh browser session to confirm it works and scopes correctly.

​

8. Sign-off records

• If your release-state machine requires sign-off, confirm every required sign-off is recorded.
• Each sign-off should have a name, role, timestamp, and (recommended) comment.
• For external audits: confirm the comment quality — “approved” is weak; “approved with awareness of acknowledged gap REQ-217 per safety engineer assessment dated YYYY-MM-DD” is auditable.

​

9. Risk-assessment linkage

• Confirm hazards.yaml is current and consistent with the safety engineer’s risk-assessment narrative.
• Confirm every hazard has at least one mitigating requirement (realised_by_requirements).
• For any hazard without mitigation: confirm the risk assessment documents why (e.g., risk acceptable without further mitigation, or mitigation is purely procedural and lives in instructions for use).

​

10. Cover letter and handoff

• Draft the cover letter from the template (see Customer handoff).
• Edit for the specific auditor and audit scope.
• Confirm the disclaimer is present.
• Prepare the pack-delivery method (signed share link, secure file transfer, in-person delivery).
• Brief the engineers who will be in the audit room. They should know which sections of the pack to point to for which questions.

​

Post-audit hygiene

After the audit:

• Record audit findings (if any) as work items in the project.
• Schedule re-verification for any findings that require fix-and-re-verify.
• Update the rationale on any acknowledged gaps the auditor scrutinised (the auditor’s questions are useful input).
• Revoke the auditor’s share link if they no longer need it (or extend if the audit is incomplete).
• Retain the audit findings document alongside the evidence pack — they belong together in the 10-year archive.

​

Common audit-blocker patterns

Things that surprise teams during audits and cause delays:

​

Next steps