What to prepare before a web product security audit

An audit is useful only when "critical" has a definition

Companies often arrive with a broad request: "check everything". It is an understandable wish and rarely the best result. Without deciding in advance which scenarios and assets are critical, the audit turns into a wide but poorly actionable document, and the business has no idea what to fix first.

What to collect before the assessment starts

• Key product scenarios: login, roles, orders, documents, payments, integrations, admin operations.
• A view of which data and actions are most sensitive for the business and its clients.
• A role and access map: who uses what, where admin rights are, who can see whose data.
• The list of external integrations and how they authenticate.
• How releases work: who deploys, how rollback happens, who is on call.

Why this matters before the audit itself

Because security risk rarely lives in a vacuum. It is tied to product logic, operations, roles, integrations and releases. The better that contour is described up front, the more useful the assessment: findings are easier to prioritise and the remediation plan gets realistic owners and deadlines.

What to agree with the provider in advance

• Which parts of the product are examined first and why those matter to the business.
• What the deliverable looks like: a risk map, priorities, ownership, fix deadlines, retesting.
• Whether a pure security audit is enough or some findings already require architecture work.

What the business gets from that preparation

The assessment stops being a formality and becomes a managed stage. The output is not a list of findings but a route: where risks are critical, who closes them, and how to fit the fixes into the existing production system without unnecessary chaos.