Engagement
From intake packet to findings walkthrough
Application audits here follow a fixed sequence so release leads know what access to grant, who we will interview, and when written findings arrive relative to your freeze date.
-
1
Intake & access
You send the application inventory, recent release notes, deploy documentation, and named contacts for build, release, and on-call. We confirm the audit window against your freeze calendar and list the repositories and environments we need to read.
-
2
Evidence review
We examine pipelines, change tickets, rollback drills, alert routing, and the last three production incidents tied to the application. Notes stay in a shared findings draft — nothing leaves your tenancy without agreement.
-
3
Stakeholder conversations
Short interviews with the release owner, a pager carrier, and one developer who ships frequently. We ask how a bad deploy is stopped today, not how the runbook says it should be stopped.
-
4
Findings register
You receive a written register with severity, evidence pointers, and suggested owners. Critical items are called out against your proposed release date so you can decide what blocks go-live.
-
5
Walkthrough
A ninety-minute session to walk the register with your team, answer challenges, and agree a remediation order. Optional follow-up review of closed items is available as a separate half-day.
What you prepare
- Named application and environments in scope
- Read access to source, pipeline, and observability consoles
- Release calendar with freeze and go-live dates
- Incident list for the prior six months
What we never do
- Change production configuration during the audit
- Run load tests without a separate agreement
- Share findings outside your named recipients