Skip to main content

Integration into an ISP process

Security Integration into Projects (ISP) is the process by which security is embedded into a project through a risk analysis that results in a signed report. IA Analyze Risk fits into this process by pre-producing the analysis ahead of workshops: you arrive with elements ready to validate, not to build from scratch.

tip

Core principle You come to workshops with elements ready to validate, not to build. IA Analyze Risk generates the analysis upstream so that workshops are used for validation and adjustment — not for thinking from scratch.

The ISP process unfolds in five main stages:


Stage 1 — Document collection

Goal: gather all existing project documentation from project managers, before opening IA Analyze Risk.

Documents to collect include:

  • Security assurance plans (provided by vendors)
  • Architecture documents
  • Pre-qualification documents
  • Specifications

In the tool: no action in IA Analyze Risk at this stage. This step prepares the inputs that will be imported in the next stage. The completeness and currency of the collected documents directly determine the relevance of the automatic pre-fill.

note

Further reading The collected documents will be imported into the scoping sheets during qualification. Scoping sheets


Stage 2 — Import and generation in IA Analyze Risk

Goal: create the project in the tool, import the collected documents, and run a full first pass to pre-fill the analysis.

What you do in IA Analyze Risk

1. Create the project

From the project list, click Create a project and fill in the basic information: name, description, lifecycle, dependency type, language.

note

Further reading Create a project

2. Assign measure catalogues

From the project detail page, assign one or more measure catalogues that will serve as the reference framework for generated remediations.

note

Further reading Measure catalogues

3. Run the qualification

The qualification has three tabs:

  • Scoping sheets: import the documents collected in stage 1, describe the project context, then link the relevant assets and processes (manually or via AI generation).
  • Questionnaire: answer the questions to assess risk factors.
  • Summary: generate the DICT summary.
tip

The more complete and up-to-date the imported documents, the more relevant the automatic pre-fill will be.

note

4. Run the risk analysis in one pass

From the Risk Analysis section, generate in a single execution the feared events, risks, and remediation measures.

note

5. Review the generated elements

Go through each generated element and adjust as needed: edit, delete, or add. The AI proposes, the cyber analyst decides.

Deliverable: a pre-filled risk analysis, reviewed and validated by the analyst, ready to be submitted to workshops.


Stage 3 — Two review workshops with the project team

Goal: validate the analysis with the project team in two one-hour sessions, using the elements already produced in the tool.

Workshop 1 (1h) — Validation of feared events and processes

Use the tool's views during the workshop to walk through the elements to validate: list of business processes, feared events, and the start of risk validation (risk sources, impacts, criticality).

caution

If the initial documents are outdated and the identified processes no longer reflect reality, this is when it will surface. Since the entire subsequent analysis is built on these processes (they are linked to feared events during qualification), it is essential to correct the baseline before moving forward.

Between the two workshops — Update and regeneration

If corrections were identified in workshop 1, update the information in the tool (scoping sheets, processes, assets) and regenerate the feared events, risks, and remediations.

info

As with all Generate buttons on the platform, you have access here to the magic wand (targeted generation) and the generation history. Learn more

note

Further reading Qualification summary

Workshop 2 (1h) — Validation of remaining elements

Continue and finalise the validation of all risks and remediations.

info

If workshop 1 required a complete rework of the processes, a third one-hour slot may be needed (total workshop time raised to 3h).

note

Further reading Feared events · Risks


Stage 4 — Remediation completion by the project team

Goal: allow the project team to fill in the implementation status of each remediation measure, asynchronously.

What you do in IA Analyze Risk

1. Export the remediations

From the project's Reports tab, export the remediations in Excel format, or share direct access to the tool with the project team.

2. The project team fills in the statuses

The project team has approximately one week to fill in, for each measure, its implementation status: already in place, in progress, planned on the roadmap, etc. They can do this:

  • directly in IA Analyze Risk (measure status field), or
  • in the exported Excel document.

3. Re-import the data if necessary

If data was entered outside the tool, re-import the statuses into IA Analyze Risk.

info

Measure statuses have a direct impact on the current matrix of the analysis summary: tracking measures updates the position of residual risks.


Stage 5 — Final report and sign-off

Goal: generate the final report, submit it for review by the project team, then collect the signature to close the ISP mission.

What you do in IA Analyze Risk

1. Generate the final report

From the project's Reports tab, generate the report in Word format.

2. Send for review (2 to 3 days)

Send the report to the project team, making clear that the review is for form, not substance: all elements of the report have already been validated in session.

caution

Be explicit with the project team: the review should not reopen substantive discussions about risks or remediations, which were already agreed upon in the workshops.

3. Sign-off and mission closure

Send the report for electronic signature. The signature closes the ISP mission.

note

Further reading Reports tab


Indicative timeline

The table below summarises the typical timeline of an ISP mission. Durations are indicative.

ActivityIndicative durationISP stage
Document collectionVariable (depends on project availability)Stage 1
Project creation, import and qualification2 to 4hStage 2
Analysis generation and review1 to 2hStage 2
Workshop 1 — Events & processes validation1hStage 3
Update and regeneration (if needed)1hStage 3
Workshop 2 — Remaining elements validation1hStage 3
(Optional workshop 3 if full rework at workshop 1)1hStage 3
Remediation completion by the project team~1 weekStage 4
Report generation and review2 to 3 daysStage 5
Electronic sign-off — ISP mission closureStage 5

note

Full tool walkthrough For a detailed description of each feature used in this process, see the My first risk analysis tutorial.