Cybersecurity audit: scope, method, evidence and a prioritised remediation plan

A useful audit does not try to prove that everything is going wrong. It reveals what is capable of stopping, exposing or deceiving the company.
Frame scenarios, demand evidence, test controls, and finance corrections in the correct order.

1. Monday, 8:12 a.m.: what the previous report missed

The financial manager receives a message from a known provider. The thread is real, the correct signature is familiar. Only the RIB has changed. At the same time, the administrator of the IT provider discovers that an old account still has remote access. The night backup is green, but no one has restored it for eighteen months. The previous diagnosis, he had 92% compliance.

This scenario is composite; it does not describe a particular client. Yet it brings together ordinary weaknesses: compromised messaging, bypassed payment process, dormant identity, provider dependency, unproven backup, reassuring overall score. None of them requires a cinema attacker. Their combination is enough.

Decorative audits are recognised for their symptoms. The scope holds in one sentence. Tests are almost entirely automated. Interviewees belong only to the IT. Critical assets are not related to operations. A technical vulnerability receives a note, but a fraud of transfer or an impossible restoration does not fit into the model. The report adds up deviations and concludes with an average.

The organisation obtains a document and does not obtain a decision.

2. Verdict: what a cybersecurity audit is

A cybersecurity audit is an independent, time-bound and evidence-based review that assesses whether the technical and organisational controls within a defined scope materially reduce the risk scenarios that matter to the organisation.

This definition contains five requirements.

• A mandate: who controls, who allows the tests and who receives the results.
• A scope: systems, sites, identities, data, premises, subsidiaries, suppliers and exclusions.
• Criteria: Public benchmarks, obligations, internal policies, expected architecture and accepted level of risk.
• Evidence: configurations, exports, logs, contracts, observations, interviews, tests and recovery exercises.
• A proportionate conclusion: findings, limits, priorities, responsibility, timelines and retest.

The exercise does not guarantee the future absence of an incident. It gives reasonable assurance of the elements observed at a given date and reveals the unknowns that prevent the conclusion. A system changes as soon as an account is created, a supplier intervenes, a corrective action arrives or a business rule evolves.

The audit does not therefore constitute a certificate of invulnerability. It is a mechanism for reducing uncertainty.

3. Key figures: 3,586 ANSSI incidents, 6,167 CNIL data breaches and 500,000 requests for assistance

The sources do not describe the same population. ANSSI reports incidents known to it; the CNIL observes notifications and inspections; Cybermalveillance.gouv.fr measures support journeys; France Num surveys business leaders; Verizon consolidates an international dataset. Adding the figures together would be a mistake. Cross-referencing them, however, reveals which surfaces should be tested.

The threat gives the scenery, the local evidence gives the verdict.

4. Audit, scan, penetration test and certification: four different exercises

In the PASSI 2.2 benchmark, the ANSSI specifies that an activity carried out entirely in an automated manner does not in itself constitute an audit activity within the meaning of the benchmark. This shade protects the buyer: a tool export feeds an investigation without replacing judgment, contextualization and contradiction.

Some organisations or contracts require a qualified provider, a specific benchmark or a formal independence. Check the contractual and regulatory obligation before choosing the provider. Never associate a general audit with a PASSI service when this is not the case.

5. The five surfaces and dependencies to be examined

5.1. Governance, assets and dependencies

The analysis begins with what the company must continue to do: invoice, produce, pay, deliver, care, respond, sell or retain evidence. These capabilities are then linked to the digital assets, owners, data, suppliers and acceptable interruption times.

The absence of an inventory is already a finding, making it impossible to cover patches, revoke access, monitor domains, classify data and prepare for recovery. NIST CSF 2.0 explicitly adds the Government function to the five historical functions: cybersecurity must be linked to decisions, responsibilities and the supply chain.

5.2. Identities, privileges and financial processes

Human accounts, service accounts, administrators, providers, OAuth, API, MFA, departures, secrets and shared boxes form the same access system. The auditor does not merely ask whether MFA “exists”. They sample critical accounts, examines exceptions, checks rescue methods and tests the removal of access.

Email security intersects with payment processes. A change of bank details, an urgent request from a senior executive or a payroll change must be verified outside the potentially compromised channel. The 21% of requests for assistance related to account compromise and the 13.5% related to payment-transfer fraud affecting businesses justify this cross-sectional reading.

5.3. Architecture, configuration, code and exposure

This area covers Internet services, firewalls, cloud, workstations, servers, applications, API, CMS, dependencies, fixes, encryption and segmentation. Depending on the mandate, it combines architecture review, configuration audit, code analysis, scan and intrusion test.

The DBIR figure of 31% places vulnerability exploitation among the leading initial-access vectors in its 2026 dataset. It does not mean that 31% of French SMEs will be compromised this way. It shows that inventory, patch management and exposure control require stronger evidence than an “everything is up to date” declaration.

5.4. Data, cloud and third parties

Where do the data reside? Who is entitled to export them? How long are they kept? Which subcontractors access it? What is left on termination? Responses go through DPO, IT, purchases, trades and suppliers.

The CNIL structures its data security guide around 25 fact sheets covering governance, users, permissions, logging, backups, continuity, cloud, mobile applications, AI and APIs. This breadth shows why a data audit cannot stop at database permissions; it must examine the entire lifecycle and its dependencies.

5.5. Detection, response and recovery

A company always ends up encountering an abnormal behaviour: impossible connection, transfer rule, EDR alert, unavailable provider, encrypted file, account created out of process. The question is about the ability to detect, qualify, decide, contain, restore and learn.

The most valuable evidence is often a timed restoration. A backup displayed in green does not demonstrate its integrity, recovery time, restoration order, or the ability to function without reinjecting compromise.

Protection reduces probability. Recovery limits impact.

6. The evidence pack to prepare

The mission costs unnecessarily when the team spends its first days looking for owners, obtaining rights or understanding conflicting exports. A pre-trial file improves coverage without prejudging the verdict.

Not every document should be sent in an unencrypted archive. The engagement agreement specifies the channel, access rights, retention and destruction. The auditor temporarily becomes the custodian of a sensitive map; the auditor’s own security is part of the service.

7. Recommended protocol: five stages, from testing to retesting

The protocol below summarizes public audit practices. It is not a Logiks proprietary method and must be adapted to the sponsor's repository, obligations and risks.

7.1. Stage 1 — Agree the rules and make testing safe

The engagement letter describes objectives, criteria, targets, exclusions, sites, time ranges, contacts, accessible data, prohibited destructive tests, handling of critical findings and stopping procedure. Intrusion tests are given specific rules of engagement and explicit authorization.

Expected output: no one discovers during the intervention that a production environment, supplier or sensitive data is within the scope.

7.2. Stage 2 — Understand the real system

Interviews, documentation, architecture, contracts and incident history are reconciled. The auditor selects a sample based on criticality and exposure: administrators, sensitive applications, subsidiaries, backups, endpoints, suppliers and financial pathways.

Crossing point: deviations between the system described and the observed system are documented prior to in-depth testing.

7.3. Stage 3 — Test the controls

The approach combines observation, configuration inspection, limited reproduction, scan, analysis and manual tests. A rule is not considered effective because it appears in a policy; it must leave an observable trace in the operation.

Examples: removing a starting account, restoring a file and then a service, triggering an alert, checking a request to change RIB, controlling a token, examining a cloud role, following a critical fix, simulating the unavailability of a SaaS.

Condition of acceptance: each important conclusion is based on reproducible evidence or clearly indicates the impossibility of obtaining one.

7.4. Stage 4 — Triangulate and prioritise

Vulnerability, assets and a scenario are linked. We assess the impact on confidentiality, integrity, availability, finance, people, obligations and reputation; we then examine exposure, likelihood, existing controls, detectability and recovery capacity.

Maturity signal: Two technically similar findings may receive different priorities if the active, the attack path or the recovery differs.

7.5. Stage 5 — Report, remediate and retest

The executive readout determines the decisions and risks accepted. The technical debrief hands over the evidence and remediation procedures. The remediation plan names owners, dependencies, timelines and closure criteria. Finally, a retest will check the important corrections.

Actual closure: A closed ticket is not proof; the correction must be observed without creating a new weakness.

8. Rank critical findings without creating an arbitrary top 50

A single score gives an illusion of precision. The CVSS helps to describe the technical severity of many vulnerabilities; it alone does not know the margin, payroll, the patients, recovery time or the dependence on a supplier.

We recommend a report sheet containing:

1. the asset and its owner;
2. observed fact and evidence;
3. the scenario of abuse or failure;
4. the business impact and the persons concerned;
5. exposure and prerequisites for exploitation;
6. existing controls, their detectability and limitations;
7. recovery capacity;
8. the recommendation, effort, dependencies and residual risk;
9. the person responsible, the deadline and the closing test.

8.1. A readable priority matrix

The number of critical findings does not measure the quality of the auditor. A good report sometimes contains few findings, while changing an essential decision. Conversely, a hundred uncontextualized alerts may immobilize the team without reducing the risk.

9. Deliverables: What a workable report should contain

The minimum delivery includes several reading levels.

• Executive summary Major scenarios, decisions, limits, accepted risks and trajectory.
• The opposable scope : assets included, exclusions, periods, accounts, techniques and samples.
• Method and limitations Reference documents, tools, assumptions, obstacles and quality of evidence.
• Detailed findings : protected facts, catches or exports, reproduction, impact and recommendation.
• Mapping dependencies Providers, identities, data, critical assets and owners.
• The Remediation Plan Priority, effort, responsibility, maturity, dependency and proof of closure.
• The risk register accepted : reason, authority, duration, compensatory control and date of review.
• The retest report : verified, partial, failed or non-testable corrections.

Sensitive elements gain to be separated from the widely distributed report. Evidence of exploitation, a partially hidden secret or a detailed diagram should not circulate in the same document as the executive committee's summary.

10. Actors, suppliers and responsibilities

Independence does not impose the absence of dialogue; it requires that the conclusion does not depend on the person whose device is assessed and that conflicts are made visible.

11. Logiks recommendations: audit controls and recovery, not paper compliance

We defend five sequencing choices.

Start with the most expensive Monday morning. Threatened messaging, altered pay, stopped production, inaccessible CRM, hijacked site: the scenario reveals assets and decisions faster than an abstract list of controls.

Ask for proof of restoration. A backup policy and a green table reassure. A timed restoration learns. It reveals dependencies, accounts, order of recovery, missing data and ability to work in degraded mode.

Follow identities beyond employees. Providers, service accounts, OAuth connectors, robots, API and emergency access hold persistent privileged access. A staff member's departure is just one case of revocation among others.

Separated made, risk and recommendation. "The MFA is not activated" describes a fact. The risk depends on the account and the path of abuse. The recommendation must then consider constraints, methods available, rescue and deployment. Mixing the three makes generic prescriptions.

Limit the first wave. Five structural, funded and counter-tested corrections are worth more than fifty recommendations attributed to "IT." The plan must reduce a measurable scenario, not just empty a table.

Our position is in one sentence: the audit is not valid for what he finds, but for the mastery that he makes possible.

12. Decision grid: what level of audit to order?

13. Eight signals from a fragile audit

1. The estimate promises a score before defining the assets and scenarios.
2. The scope refers to the "information system" without a list, environment or exclusion.
3. The main part of the service consists of launching a scanner and then exporting its results.
4. No business manager is asked about payments, production, data or continuity.
5. Active tests do not have commitment rules and a standstill procedure.
6. Sensitive evidence passes through regular e-mail or remains retained without a defined duration.
7. All recommendations go to the same owner and the same deadline.
8. The report does not foresee any contradiction, acceptance of risk or retest.

A ninth signal deserves special attention: the auditor states what they could not observe without turning the lack of evidence into an explicit limit. Uncertainty is not a weakness of the relationship when it is honest. It becomes a weakness when it is hidden.

14. 90-day remediation plan

14.1. Days 0–7 — Contain what cannot wait

• treat exposed P0s and secrets;
• preserve logs and evidential material;
• disable obvious orphaned accounts;
• closing unjustified Internet services;
• verify crisis contacts, insurers and providers;
• inform management, DPO or authorities when required by the framework.

14.2. Days 8–30 — Reduce the main attack paths

• generalize the MFA on critical accounts and deal with exceptions;
• correcting the priority exposed vulnerabilities;
• test the restoration of essential services;
• secure changes in bank details;
• review administrators, third party access and service accounts;
• name each risk, owner and proof of closure.

14.3. Days 31–60 — Build the organisational foundations

• make inventory and classification reliable;
• up-to-date responsibilities of suppliers;
• define logging, alerts and escalation;
• align retention, personal data and backups;
• document the degraded mode and order of recovery;
• train teams on their concrete decisions, not with a generic module.

14.4. Days 61–90 — Verify and govern

• retest P1 and structural corrections;
• conduct a crisis exercise on the table;
• measure the timeframes for correction, revocation, detection and restoration;
• formal acceptance of residual risks;
• integrate recurring controls into the operating schedule;
• present to management reduced scenarios, unknowns and the next review.

15. FAQ

15.1. How much does a cybersecurity audit cost?

The price depends on the scope, the number of assets, the types of tests, the accesses, the travels, the repositories, the level of insurance, the qualification required and the retest. A serious estimate separates scoping, evidence collection, testing, reporting and verification. Compare only a number of days without comparing coverage and deliverables leads to the purchase of different objects.

15.2. How long does the intervention last?

As a Logiks operational benchmark, a targeted review often requires five to ten days of work over two to three weeks. An SME audit covering organisation, technical, data and continuity spans more than two to five weeks. A multi-site, applied or regulated scope easily exceeds this duration. These ranges are not market averages; they are used to plan accesses, interviews, tests and contradictions.

15.3. What is the difference between a cybersecurity audit and a penetration test?

The penetration test seeks to demonstrate attack paths in precise rules. The audit more broadly appreciates the effectiveness of technical and organisational controls in terms of a scope and criteria. It sometimes includes a penetration test; the latter generally does not cover any safeguards, contracts, governance or crisis capacity.

15.4. Does an audit demonstrate compliance with the GDPR?

The service examines the security obligation, access, subcontractors, retention and personal-data-breach management. It does not automatically prove the full compliance of all processing. GDPR compliance also covers purposes, legal bases, transparency, rights, minimisation and documentary governance.

15.5. Should a PASSI provider be selected?

This depends on the context. Certain contracts, regulations or levels of sensitivity may require or justify a qualification. The PASSI repository supervises the provider, his staff and the conduct of qualified activities. If no obligation applies, its categories remain useful to understand the types of audit, but an unqualified service should not be presented as equivalent.

15.6. Can the internal audit be carried out?

A self-assessment effectively prepares the inventory and the first corrections. Independent intervention brings contradiction, comparison, expert expertise and credibility with third parties. For very sensitive topics, combine internal team, external auditor and professional expert; document conflicts of interest.

15.7. What should be prepared before starting?

A sponsor, scope, critical processes, available inventory, key contracts, identity exports, backup evidence, past incidents and key contacts. Don't wait for everything to be perfect: the absence or inconsistency of evidence is already information, provided you don't hide it.

15.8. How often should we start over?

The frequency depends on the change and the risk. An annual review may be insufficient if the company launches an application, migrates to the cloud, changes provider, acquires a company, undergoes an incident or renews its architecture. Between two audits, continuously follow accesses, assets, vulnerabilities, backups and suppliers.

16. Conclusion

The serious approach does not end with an overall colour. It links an asset to a proof, a weakness to a scenario, a scenario to an impact, then a correction to a owner and a retest.

This chain changes the conversation. Management no longer asks if the company is "secure". It chooses the interruptions it refuses, the data it needs to protect, the dependencies it accepts and the evidence it requires.

It's no longer a compliance photograph. It's a master's architecture.

17. Main sources

1. ANSSI — Panorama of the cyberthreat 2025published on March 11, 2026, consulted on July 13, 2026.
2. CNIL — Annual Report 2025published on 18 May 2026, consulted on 13 July 2026.
3. Cybermalveillance.gouv.fr — Activity report and threat status 2025published on 26 March 2026, updated on 8 June 2026.
4. Cybermalveillance.gouv.fr — Main cybermalveillances targeting professionals in 2025published in 2026, consulted on 13 July 2026.
5. Directorate-General for Enterprise — Barometer France Num 2025June 2025 survey, consulted on July 13, 2026.
6. Verizon — Data Breach Investigations Report 2026published in June 2026, consulted on 13 July 2026.
7. ANSSI — Updating the PASSI 2.2 and PRIS 3.0 Repository, PASSI version 2.2 of one August 2024, consulted on 13 July 2026.
8. NIST — Cybersecurity Framework 2.0published in February 2024, consulted on 13 July 2026.
9. CNIL — Guide to Personal Data Security, edition 2024, consulted on 13 July 2026.