The checklist we use before any security audit

A security audit without business context produces a vulnerability report ordered by technical severity, with no prioritisation by real impact. The result is a document nobody reads fully and that generates more anxiety than action. Before any technical audit, we run a preparation process that determines what to look for, where to look and how to interpret what we find.

The value of an audit is not in the vulnerability list: it is in knowing which vulnerabilities affect the systems that matter most to the business, how likely they are to be exploited in your real context and what impact an incident on each one would have. Without that context, a critical finding on an obsolete system nobody uses is less urgent than a medium one on the billing system processing all your transactions.

• What are the three business processes that cannot stop under any circumstances?
• What data does the company handle with the highest regulatory sensitivity (personal, financial, health)?
• Have there been security incidents in the last 24 months, even minor ones? How were they resolved?
• What is the most likely threat profile for this sector and company size?
• Are there technology change projects underway or planned that affect the security perimeter?
• What regulatory requirements apply (GDPR, NIS2, ENS, PCI, sector-specific)?

• Complete list of active systems with owner, function and business criticality
• Data flow map: what data goes from which system to which and via what channel
• Internet-facing systems: which have a public surface and since when
• SaaS applications in use: how many, who manages them and what data they contain
• Network devices: endpoint inventory including mobile devices and remote work equipment
• Legacy systems: which systems have active support and which are out of the update cycle
• System integrations: what connects to what and whether those connections are documented

• Is there a centralised identity directory (AD, Entra ID, Okta) or is access managed per system?
• Is there a documented user onboarding and offboarding process?
• Which systems have MFA enabled and which do not?
• Are there service accounts or application access not linked to identified individuals?
• Have administrative privileges been reviewed in the last 6 months?
• Are there active third-party accesses (suppliers, consultants, ex-employees) that should be closed?

• Is there an IT incident log from the last 12 months?
• Were there any incidents involving unauthorised access, data loss or extended unavailability?
• Are backup restoration tests run on a documented schedule?
• Is there a formal incident response plan, even a basic one?
• Who (which supplier or internal person) would be the first contact in a serious incident?

This preparation process takes 2-4 hours of joint work with the client. It is the most valuable investment in the project: it allows technical findings to translate directly into an action plan prioritised by business impact, not abstract technical severity.