Skip to content
A review you can act on

Know what to verify next.

Six questions help you locate gaps in the evidence for your software. Answer for one system and the scope you are reviewing.

Answers stay in this browser. They are not sent to Taiga or analytics. Copying your notes is an explicit action you control.

This is a self-assessment, not an audit, certification or automated release gate. “Yes” records your answer; it does not verify the evidence.

  1. Can you trace a recent production change to its requirement, review and named approval?

    Choose one recent change. Collect the requirement, pull request, test result and approval record; identify any missing link.

    Review the related readiness questions
    • Could you produce a record of who changed what, when, and why?
    • Did every change go through a documented change-control step?
    • If AI is in the loop, could you show conformity evidence this quarter?
    • Are its logs centralized and retained per your policy?

  2. Do you have an owned process to assess vulnerabilities, prioritize fixes and verify them afterward?

    Find the latest scan, its scope and age. Name the owner of each relevant finding and collect evidence from a fresh scan after remediation.

    Review the related readiness questions
    • Was the code hardened against a written security policy, not reviewed by eye?
    • Are its IAM roles least-privilege, and has anyone checked since launch?
    • Are all secrets out of the code, stored and rotated?
    • Do you have a current SBOM and a patch cadence?

  3. Have you tested recovery for the failures your service needs to withstand?

    Write down the recovery objective, responsible operator and last exercise result. Plan a test for an important untested failure.

    Review the related readiness questions
    • Would you know it is degrading before a user tells you?
    • Is someone on call for it, in writing?
    • Are SLOs and error budgets defined?
    • Has a backup ever been restored on purpose, as a test?
    • Would it survive one availability zone failing?

  4. Could a new maintainer build, change and operate the system using the available documentation and access?

    Ask a maintainer unfamiliar with the system to follow the build and operating instructions. Record missing context, access and ownership.

    Review the related readiness questions
    • Are its integrations (ERP, IdP) documented outside the code?
    • Does the documentation match what actually shipped?
    • Do its tests check what the business asked for, not just what the code does?
    • Could you rebuild the environment from the repository alone?
    • Is there a tested rollback path, versioned with the delivery?

  5. Can you identify the personal data, its storage and access, and the relevant retention and deletion rules?

    Trace a representative record through the system. Check storage locations, processors, permissions and deletion behavior against the documented rules.

    Review the related readiness questions
    • Is threat detection watching it in production right now?
    • Can you show where its data lives, and prove it stays there?

  6. Have you identified the obligations that apply to this system and linked them to evidence and an accountable owner?

    Map the applicable contractual, security and regulatory obligations to evidence. Record missing evidence and the person who will resolve it.

    Review the related readiness questions
    • Did a DPIA exist before the build started?
    • Does a written threat model exist for it?