Periodic Risk Review Policy
1. Objective
This policy defines the mandatory mechanisms for reviewing the application risk classification and the associated security controls throughout the entire lifecycle of each application.
Risk classification is not a one-off onboarding act - it is a dynamic state that must be kept up to date. Technical, business or regulatory changes may modify the exposure, the data processed or the potential impact of an incident, without this being immediately visible. Without structured review, the classification ages silently and the controls applied cease to be proportional to the real risk.
This policy establishes two complementary review mechanisms:
- Time-based - review at a fixed periodic cadence, independent of changes
- Event-based - review triggered by relevant technical or business events
2. Scope
This policy applies to all applications with an active risk classification (L1, L2 or L3), regardless of their development status (under construction, in production, in maintenance or being discontinued).
Applications in the process of decommissioning retain the review obligation until their formal deactivation and the recording of their closure.
3. Time-based review - periodic cadence
3.1 Mandatory minimum cadences
| Level | Minimum cadence | Mandatory status |
|---|---|---|
| L1 | Annual (12 months) | Mandatory |
| L2 | Half-yearly (6 months) | Mandatory |
| L3 | Quarterly (3 months) | Mandatory |
The date of the next review must be recorded in the classification document at the time of each review. The absence of a scheduled review date is treated as non-compliance.
3.2 What to assess in each periodic review
- Reassessment of the three axes E, D and I based on the current state of the application
- Verification of technical changes since the last review (new integrations, changes in exposure, new data types)
- Verification of business changes with a potential impact on the risk level
- Review of the status of the controls applied and of their adequacy to the current level
- Review of the accepted residual risks and of their validity
- Documented decision: keep the level / change the level
- Scheduling of the next review
3.3 Outcome of the periodic review
| Decision | Action |
|---|---|
| Level maintained | Record the reassessment with date, owner and justification; schedule the next review |
| Level raised | Update the classification; review the mandatory controls; communicate to the teams; obtain approval |
| Level lowered | Update the classification with detailed technical justification; obtain AppSec approval |
Lowering the criticality level requires rigorous technical justification and approval by an AppSec Engineer. It is not acceptable to lower the level solely for reasons of operational convenience or to reduce the compliance effort.
4. Event-based review - mandatory triggers
4.1 Triggers that require an immediate review
The review of the classification must be triggered immediately — started within at most 5 working days and completed within 30 days — when any of the following events occurs:
| Trigger | Description |
|---|---|
| New external integration | Connection to an external system, third-party API or cloud service not previously foreseen |
| New type of sensitive data | Start of processing of PII, regulated data, health data, financial data |
| Change in exposure | Opening of a new public endpoint, authentication removed, new access channel |
| Significant architectural change | Change of deployment model, infrastructure migration, addition of a critical component |
| Introduction of automation or AI | When it modifies exposure, the data processed or the impact of decisions |
| Relevant security incident | Any incident that reveals a misalignment between the classified level and the real risk |
| Applicable regulatory change | New legal or normative obligation with an impact on the classification |
| Change of business model | Change in the target audience, jurisdiction or purpose of the application |
4.2 Triggers that recommend a review
The following events do not require an immediate review, but must be assessed by the team as potential triggers:
- Significant change in the volume of data processed
- Addition of new user profiles with different access levels
- Change of the responsible team or of the security owner
- Pentest results that reveal exposure not foreseen in the classification
4.3 Event-based review process
- Identify the trigger - document the event that gave rise to the review
- Assess the impact on the E, D and I axes
- Determine whether the level must be changed
- Document the decision with clear technical justification
- Obtain approval from the approval authority appropriate to the resulting level
- Update the classification document and communicate to the teams
- Restart the calendar of periodic reviews based on the new level
5. Tool-assisted detection
The organisation may use automated tools to detect events that may constitute review triggers (e.g. analysis of commits, PRs, configuration changes).
When a tool proposes reclassification or alerts to a potentially relevant change:
- The alert must be assessed by an AppSec Engineer before any decision
- Patch updates to dependencies do not constitute, in themselves, a review trigger
- Minor/major changes to critical dependencies must be assessed
- The final decision is always human - the tool signals, it does not decide
6. Mandatory documentation of each review
Each review (periodic or event-based) must produce a record with:
- Date of the review
- Type of review (time-based / event-based)
- Trigger (for event-based) or cadence (for time-based)
- Reassessment of the E, D and I axes
- Decision: level maintained / changed (with justification)
- Status of controls and accepted risks verified
- Person responsible for the review
- Approval (if applicable)
- Date of the next scheduled review
Main artefact: an entry in the application's classification document (risk-classification.md or equivalent), with the history of all previous reviews preserved.
7. Integration with the development lifecycle
| Moment | Expected action |
|---|---|
| Sprint planning (L3) | Check whether any event-based trigger occurred in the previous sprint |
| Release / go-live | Confirm that the classification is up to date and within its cadence |
| Incident retrospective | Check whether the periodic review would have detected the problem |
| Onboarding of a new team | Check the date of the last review and start a new one if necessary |
8. Responsibilities
| Role | Responsibility |
|---|---|
| AppSec Engineer | Conduct and approve reviews; monitor the review calendar per application |
| Tech Lead / Developer | Identify and report technical events that may constitute triggers |
| GRC / Compliance | Monitor compliance with the cadences; issue alerts for overdue reviews |
| Product Management | Communicate business changes with a potential impact on the classification |
| CISO | Oversee the review programme; ensure organisational coverage |
9. Non-compliance
The absence of a review within the cadence defined for the level constitutes non-compliance with this policy and must be:
- Recorded as a non-conformity in the GRC system
- Escalated to the AppSec Engineer and the CISO
- Resolved through an immediate review and a record of the cause of the delay
10. Review and audit of this policy
This policy must be reviewed annually or after any of the following events:
- Change to the SbD-ToE classification model
- Incident originating in an outdated classification
- Regulatory change with an impact on the mandatory review cadences
The review history of all applications must be made available in internal and external security audits.
11. Normative and technical references
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 01 - Application Classification | E+D+I model, review cadences, event-based triggers |
| SbD-ToE Ch. 14 - Governance and Contracting | Continuous cycle of review and reassessment of exceptions |
| ISO/IEC 27001 - Clause 6.1 | Risk assessment and treatment with periodic review |
| NIST SP 800-30 | Guide for Conducting Risk Assessments |
| NIST CSF - Identify (ID.RA) | Risk Assessment with continuous review |
| SSDF PW.1 | Risk-based definition and review of security requirements |