LPM audit: requirements, preparation and stakeholders

For an operator of vital importance (OIV), auditing its critical information systems is not optional: the French Military Programming Law (LPM) requires it, whether the goal is to accredit a critical system or to respond to an inspection ordered by the State. Well prepared, the audit becomes a management tool. Poorly prepared, it turns into a scramble for documents in the days before the kick-off meeting.

This article summarizes what the framework requires, proposes a method to organize audit preparation, and lists the stakeholders to involve on the operator's side, the government's side and the service providers' side.

The LPM in a nutshell

Article 22 of the Military Programming Law of December 18, 2013 introduced cybersecurity obligations for operators of vital importance into the French Defence Code (articles L. 1332-6-1 et seq.). OIVs are designated by the State within the sectors of vital importance (energy, transport, health, finance, electronic communications, food, water, etc.), because the unavailability of their activities would seriously affect the life of the nation.

The framework applies to information systems of vital importance (SIIV): systems whose compromise would disrupt those vital activities. The operator identifies its SIIVs and declares the list to ANSSI, the French national cybersecurity agency. Decree No. 2015-351 of March 27, 2015 sets the general framework, and sector-specific orders define, for each sector, the security rules, the implementation deadlines and the types of incidents to report.

In practice, an OIV must in particular:

• identify its SIIVs and send the list to ANSSI;
• apply the security rules set by its sector order;
• report security incidents affecting its SIIVs to ANSSI without delay;
• have its SIIVs audited, notably as part of their accreditation, and submit to inspections ordered by the State.

Requirements: twenty rules in four families

The sector orders share a baseline of twenty security rules, which ANSSI groups into four families. This is the audit's frame of reference: every finding will be mapped to it.

A few rules usually account for most of the compliance effort:

• Mapping. It must describe the SIIV's software and hardware components, interconnections, flows and administrative access. Without an up-to-date map, neither the audit scope nor its conclusions can be relied on.
• Administration. Dedicated administrator accounts, administration workstations and systems separate from office IT, strong authentication: this is an attacker's preferred path, and therefore a central focus of the audit.
• Segmentation and filtering. The SIIV must be isolated from other systems, and only strictly necessary flows may be allowed and documented.
• Security maintenance. Vulnerability monitoring, patching, and handling of obsolete or unpatchable systems with documented compensating measures.
• Detection. The orders provide for detection systems, operated by the operator or by a qualified provider (PDIS), and for log retention.

Accreditation or inspection: two audit contexts

An LPM audit takes place in one of two contexts, which should be distinguished from the start because they are not prepared in quite the same way.

The pre-accreditation audit

The accreditation rule requires the operator to accredit each SIIV, then to renew the accreditation at the interval set by the order. The accreditation file includes a security audit carried out by a PASSI-qualified provider (the "PASSI LPM" qualification) or by a government service. The operator selects and engages the provider, and the accreditation authority decides, based on the report, whether to accept the residual risks.

The inspection ordered by the State

Independently of accreditation, the Prime Minister may require an OIV to undergo an inspection of the security level and rule compliance of its SIIVs. The inspection is carried out by ANSSI or by qualified providers, at the operator's expense. Here the initiative, scope and schedule come from the administration: the operator's room for manoeuvre lies mainly in its ability to provide the requested information quickly.

Organizing audit preparation

Preparing for an LPM audit is a project in its own right, with a lead, a schedule and deliverables. Here is a six-step approach.

1. Appoint a lead and set the objective

A single lead, usually the CISO or a member of their team, coordinates preparation and acts as the audit provider's point of contact. The objective must be formalized: initial accreditation, renewal, response to an inspection, or a readiness audit ahead of one of these milestones. It drives the scope, the depth of testing and the report due date.

2. Define the scope

The scope starts from the list of SIIVs declared to ANSSI, then is refined with the map: sites, components, interconnections, administration systems, third-party access (maintenance contractors, managed service providers, software vendors). Components outside the operator's direct control, such as outsourced hosting or a service run by a subcontractor, must be identified early: auditing them requires the third party's consent and availability, which is rarely negotiated in a few days.

3. Self-assess against the twenty rules

Before the auditors arrive, review each rule of the sector order: measure in place, partial measure, known gap. This self-assessment does not replace the audit, but it avoids discovering during the engagement gaps the team already knew about, and it lets simple fixes start beforehand. Accepted gaps (an obsolete system kept for business reasons, for example) must be documented together with their compensating measures.

4. Select the provider and frame the engagement

Check the provider's qualification in ANSSI's catalogue, and its scope: PASSI covers five activities (architecture audit, configuration audit, source code audit, penetration testing, organizational and physical audit), and a provider is not necessarily qualified for all of them. The PASSI framework requires an audit agreement signed before the engagement starts, setting out the scope, activities, terms, responsibilities and confidentiality rules. It is supplemented by an audit plan detailing the schedule and the interventions.

For an SIIV, also plan for context-specific constraints: auditor security clearance if classified information is involved, site access conditions, handling and storage of audit data, retention of evidence.

5. Gather the documentation

The auditors will need the reference documents from the kick-off meeting, or even earlier for the organizational audit. Set up a single, access-controlled document repository that includes at least:

• the security policy and its provisions applicable to the SIIV;
• the map and the architecture and flow diagrams;
• the previous accreditation file and the follow-up of its action plan, if any;
• administration, account management and access rights procedures;
• security maintenance procedures and patch status;
• the logging policy, and how detection and incident handling are organized;
• the crisis management plan and exercise reports;
• contracts and agreements with third parties working on the SIIV;
• the indicators sent to ANSSI.

6. Prepare the technical logistics

Technical audits fail more often on logistics than on technique. Plan ahead for:

• the required accounts (read-only for the configuration audit, test accounts for penetration testing);
• configuration exports (firewalls, switches, directory, systems);
• physical access and the audit workstation, including on an isolated administration system;
• testing windows compatible with operations, especially on industrial systems;
• written authorizations, and notification of operations teams, the SOC and relevant third parties;
• an escalation contact reachable throughout testing.

Stakeholders to involve

An LPM audit involves far more than the security team. Identifying stakeholders and notifying them early is the best way to keep to the schedule.

On the operator's side

On the government's side

• ANSSI, the national information systems security authority: it receives the SIIV list, incident reports and indicators, conducts or commissions inspections, and supports operators through its sector coordinators.
• The ministry coordinating the sector and its senior defence and security official (HFDS), the OIV's usual point of contact on vital importance matters.

On the service providers' side

• The PASSI-qualified audit provider: its lead auditor is your single point of contact for the agreement, the audit plan, the kick-off and closing meetings and the report.
• Providers operating part of the SIIV: managed service provider, host, maintenance contractor, detection provider (PDIS). Their consent and involvement are prerequisites for auditing the components they run.
• The incident response provider (PRIS), if under contract: it is worth informing them of the testing period.

During and after the audit

The engagement opens with a kick-off meeting that restates the scope, rules of engagement and contacts. During testing, the lead auditor reports any critical vulnerability without waiting for the report, so the operator can address it immediately. The closing meeting presents the initial findings, and the final report details each vulnerability, its risk level and the related recommendations.

The work does not end with the report. The operator then needs to:

• build an action plan with an owner, a priority and a due date for each recommendation;
• formalize the residual risks submitted to the accreditation authority;
• verify the most critical fixes, ideally with a follow-up audit;
• reassess accreditation whenever the SIIV changes significantly.

Preparation checklist

• Applicable sector order identified and reviewed
• Audit objective formalized (accreditation, renewal, inspection)
• Lead appointed, accreditation authority and DDS informed
• SIIV list and map up to date
• Third-party-operated components identified, consent obtained
• Self-assessment against the twenty rules completed
• Provider's PASSI qualification checked in ANSSI's catalogue for the planned activities
• Audit agreement and audit plan signed
• Documentation gathered in an access-controlled repository
• Accounts, exports, physical access and testing windows ready
• Operations, SOC and third parties notified, escalation contact appointed
• Action plan follow-up and follow-up audit scheduled