Information system mapping: ANSSI’s 5 steps explained

An information system map is not a static drawing. ANSSI presents mapping as a tool for mastering the information system, supporting protection, defence and resilience, and its guide describes a practical five-step approach designed to progress incrementally.1

The difficult part is rarely producing the first diagram. It is building a repository that is precise enough to answer operational questions and manageable enough to stay current. A map can therefore start small, provided its model, ownership and intended use are explicit.

FIG. 01The lifecycle of a useful information system map

01 / ScopePurpose & perimeter

02 / ModelObjects & relationships

03 / ToolRepository & views

04 / BuildPriority data

05 / SustainGovernance & updates

The five ANSSI stages translated into practical decisions

1. Start the initiative: begin with the question, not the inventory

The ANSSI guide starts with objectives, scope, stakeholders, needs and the expected level of detail.1 A map created for an audit does not need exactly the same granularity as one used during incident response or disaster-recovery planning.

Before collecting thousands of objects, write down five things: purpose, scope, users, questions to answer and update frequency. This prevents mapping from becoming an endless inventory programme.

Typical starting questions include: which applications support a critical process? Which identity, database or cloud services do they depend on? Which flows cross a trust boundary? Which components must be restored before others?

2. Define the model: decide what each object means

ANSSI recommends using existing inventories and diagrams, then defining a common representation model.1 This is where the organisation decides what it means by an application, service, logical server, site, flow or third party — and which relationships can connect them.

A minimal dictionary might include: Process → supported by → Application; Application → exchanges with → Application; Application → hosted on → Infrastructure; Application → depends on → Identity; Third party → provides → Service.

The useful rule is not to create an object type because it might be interesting. Create it because it helps answer a question. An excessively rich model increases collection and maintenance cost without guaranteeing better understanding.

3. Select tooling: prioritise the repository over the drawing

The tool produces views, but its value depends on whether it can store objects and relationships, search them, import them, track changes and generate several representations from the same facts.

ANSSI does not prescribe a particular product.1 Operational criteria therefore matter: access control, an extensible model, import/export, history, the ability to connect existing data sources, views for different audiences and mechanisms that keep data current.

A spreadsheet or drawing tool may be enough for a prototype. It becomes fragile when several teams must share the data or when the same application needs to appear in business, flow and infrastructure views without being re-entered three times.

4. Build incrementally: complete one dependency chain first

The progressive approach described by ANSSI favours a useful perimeter over superficial coverage of the whole environment.1 A strong first iteration can be one critical application with its business process, identities, data, major flows, hosting and third parties.

That chain is more informative than hundreds of unconnected application names. It also tests the model: if the team cannot represent a well-known service cleanly, it is better to correct the structure before scaling collection.

5. Sustain the map: turn it into an operating process

The fifth stage of the ANSSI guide explicitly addresses sustainability, including governance, communication and maintenance.1 This is often what separates a useful map from a one-off deliverable.

Each family of data should have an owner or at least an identified system of record. Application data may come from a portfolio, servers from inventory tooling, cloud accounts from the cloud organisation and business criticality from continuity management. The map does not have to become the master of every field; it must know where data comes from and how facts connect.

The data model matters more than the beauty of the view

A view can be easy to read and still be misleading if it does not state its scope or freshness. Conversely, a structured repository can generate several views without duplicating facts.

Three distinctions are particularly useful:

object: application, process, server, third party;
relationship: “depends on”, “exchanges with”, “hosted on”, “provided by”;
view: a selection of objects and relationships used to answer a question.

This separation also makes automation easier. A technical source can update cloud resources without deciding business criticality; a business owner can qualify a process without editing network topology.

Four mistakes that make a map unreliable

Treating completeness as the same thing as usefulness

An incomplete repository with an explicit perimeter can be useful. A repository presented as exhaustive when it covers only part of the environment is dangerous. Scope and verification date should be visible.

Collecting objects without relationships

An inventory answers “what do we have?”. A map must also answer “how do those elements depend on one another?”. Relationships turn the list into a model of the system.

Adding detail without a clear use case

Documenting every interface, network port and cloud resource may be appropriate for a specific technical scope. Doing it everywhere by default creates a maintenance burden. Granularity should follow the decision the map is meant to support.

Forgetting the update mechanism

The map becomes stale because the system changes: a new SaaS service, a hosting migration, merged applications, a changed flow or a new dependency. A sustainable map specifies how those changes are detected, who validates them and how frequently critical views are reviewed.

The quality test: which decisions become easier?

A map is not better because it contains more objects. It becomes useful when it reduces the time needed to understand impact: what is critical? what does this service depend on? where does data flow? which third parties are involved? what needs to be restored first?

This test can be applied during design. If no recurring decision or question depends on a field, object or relationship, its collection deserves scrutiny.

CNIL recommends identifying processing activities, categories of personal data, purposes, stakeholders and data flows, including origins and destinations.2 It also recommends identifying processing activities by purpose rather than by the software used, because one application can support several processing activities and one activity can rely on several tools.3

An information system map and a GDPR record should therefore not be merged. They can, however, share junction points: an application can be linked to the processing activities it supports, the data it handles, relevant flows and hosting.

A ten-question launch checklist

Before starting or restarting an information system mapping programme, ask:

What problem are we trying to solve first?
What is explicitly in — and out — of scope?
Who uses the map and for which decisions?
Which object types are actually necessary?
Which relationships must be preserved?
Which data sources already exist?
Which source wins when facts conflict?
Who validates business and technical information?
How does a system change trigger an update?
How do we know a view is still trustworthy?

This approach does not guarantee an exhaustive map. It aims at something more useful: a repository that is understandable, governed and improvable, capable of growing with the information system rather than ageing beside it.