Prove guides

Step-by-step, least-privilege setup for every source — GitHub, GitLab, the clouds, and AI spend.

How each score is computed, the connectors, tenant isolation, and the board pack.

Keep evidence in eight categories: access, change, vulnerability, logging, training, incident, vendor, and policy. Each proves a control operated, not merely that it was designed. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.

Set retention per artifact, not per organisation. A few periods are fixed by law or contract — PCI DSS asks for 12 months of audit logs. Most are your own defensible choice, commonly 12 months plus the audit period. Not legal advice.

GitHub evidences three control areas well: change management through rulesets and pull-request records, access through organisation and repository permissions, and vulnerability management through Dependabot, code scanning, and secret scanning. This page is not legal advice, does not determine YOUR obligations, and does not file with an auditor.

GitLab evidences change management through protected branches and merge-request approval rules, access through group and project membership, and vulnerability management through its security scanners and vulnerability report. Several of those are Premium- or Ultimate-gated.

CloudTrail evidences who did what, AWS Config evidences configuration state over time, IAM and Access Analyzer evidence authorisation, and Security Hub aggregates control status. AWS's own certifications cover the infrastructure layer, not your configuration. Not legal advice.

Microsoft Entra ID evidences identity and access, activity and diagnostic logs evidence what happened, Azure Policy evidences configuration standards, and Defender for Cloud aggregates control status against framework references. Microsoft's certifications cover the platform, not your configuration.

Cloud Audit Logs evidence who did what, IAM policy and Policy Analyzer evidence authorisation, Security Command Center aggregates posture and produces compliance reports, and Cloud KMS evidences key control. Google's certifications cover the platform, not your projects.

The pipeline evidences four things well: that required checks ran and passed, that the build produced a traceable artifact, that deployment needed an approval from someone other than the author, and that run history is retained. SLSA levels are best practice, not a requirement.

Access control is evidenced across a lifecycle: an approval before provisioning, a record of the grant, a periodic review with a named reviewer, and a removal record on departure. Enforcement configuration supports each stage.

Four artifacts carry the programme: proof of scan coverage across the whole estate, a written prioritisation rationale, remediation records measured against your own stated targets, and risk-acceptance records for what you did not fix.

The useful SBOM evidence is one machine-readable inventory per released version, generated by the build, stored with the artifact, and queryable when an advisory lands. Format matters less than coverage, versioning, and retrievability.

Four artifacts do most of the work: a committed lockfile per project, the update pull-request history, remediation records for known-vulnerable packages, and a licence inventory per release. Licence obligations are legal; update cadence is your own standard.

An audit-acceptable test has a documented scope covering the in-scope environment, a stated methodology, an independent tester, dated findings with severity, remediation records, and retest evidence. A vulnerability scan is not a penetration test and does not substitute for one.

Keep four things: the curriculum with its approval date, completion records naming every person and date, policy acknowledgements, and — where you run them — phishing-simulation results with what you did about them. Completion percentages without a named population prove little.

A pull request with an independent approval, a passing required check, and a deployment record authorised by someone other than the author satisfies the intent of most change-control criteria. What auditors add is the complete population and the emergency-change path.

Preserve the detection record, the decision timeline with timestamps, the severity and reportability decisions with who made them, internal and external communications, containment and remediation actions, and the post-incident review. Preserve them before you triage, not after.

Keep an AI system inventory with a risk classification per system, a risk assessment per system, model and dataset documentation, human-oversight records, records of AI-assisted changes to your own code, and post-deployment monitoring output.

For most companies: twelve months as the working baseline for security-relevant logs, with the most recent three months immediately searchable, plus whatever your audit period, incident-reporting windows, and contracts require. Very few log types have a legal minimum at all.

Organise by control rather than by source, name files so the control, artifact, period, and capture date are readable without opening them, keep an index that maps every control to its evidence, restrict access, and track a freshness date per artifact.

Collecting control evidence on a schedule from connected systems rather than screenshotting configurations before an audit. It gives you a period record instead of a snapshot, and it makes drift visible while you can still fix it.

Show two things separately: that the control is designed to prevent or detect the risk, and that it operated that way throughout the period. The second needs a complete population, a sample drawn from it, and no exceptions you cannot explain.

Keep the signed authorization, scoped report, remediation records, and retest confirmation. Limit who can read exploit detail. Retention follows YOUR framework and counsel — this page does not set YOUR period. This page is not legal advice.

ShipReady Metrics organizes pen-test reports, scan results, SAST/DAST findings, remediation, and retests as reviewable, framework-mapped evidence. It does not replace an independent pen test and does not issue a certification. This page is not legal advice.

A technology due diligence checklist covers architecture, code quality, security, scalability, IP and licensing, team, and operations — sized to maturity. It is a preparation aid, not a pass/fail score. This page is not legal advice and not investment advice.

A cybersecurity due diligence checklist walks control domains, vulnerability posture, incident history, supply-chain risk, data-protection exposure, and certifications — verifying scope and dates, not logos. Prior-breach silence is itself a risk. This page is not legal advice.

An AI due diligence checklist covers model inventory, training-data provenance and rights, governance and risk, and whether the EU AI Act, ISO/IEC 42001, or NIST AI RMF is even in play. This page does not determine that the Act applies to YOU. It is not legal advice.

Investors look for scalable architecture, a team that is not a single point of failure, honest quality and security evidence, and a roadmap that matches the codebase. Red flags include fake certifications and missing denominators. This page is not investment advice and not legal advice.

Private-equity diligence weighs delivery predictability, engineering unit economics, technical-debt burden, and key-person risk — efficiency and EBITDA more than top-line growth alone. Metrics need denominators. This page is not investment advice and not legal advice.

Acquisition security diligence runs in phases — pre-LOI scoping, confirmatory evidence, then integration and remediation — so inherited risk is priced before close. Verify certifications by scope and date. Reps and warranties are counsel’s work. This page is not legal advice.

OSS diligence inventories dependencies (SBOM), license-family obligations, provenance, and known vulnerabilities. Permissive and copyleft licenses are different obligation sets. This page does not interpret a license for YOU. It is not legal advice.

Assess technical debt by type — quality, architecture, operational, and knowledge — then estimate remediation as a ranged cost with assumptions. Do not treat one metric as a verdict. This page is not investment advice and not legal advice.

AI-authored code raises unsettled IP and copyright questions plus measurable risks — license contamination, insecure patterns, and unknown authorship share. Measure the engineering risk; leave ownership to counsel. This page is not legal advice and not investment advice.

Prepare on a 90/60/30-day clock: inventory and gaps first, then evidence and metrics, then a clean data room and rehearsal. Surprises in confirmatory are usually missing artifacts, not new physics. This page is not legal advice and not investment advice.

An engineering readiness report states scope, metrics with denominators, security and compliance posture, a risk register, and a remediation plan in one artifact. Honest coverage beats cherry-picked greens. This page is not legal advice and not investment advice.

ShipReady Metrics supports diligence by sharing posture (Passport), scoring readiness (A–E), mapping controls with disclosed density, and attaching evidence, vulns, AI inventory, and DORA metrics. It does not close a deal or replace counsel. This page is not legal advice and not investment advice.