Skip to main content

Continuous Validation and Reviews

This annex describes the mechanisms for recurring validation of applications, suppliers and contracts, so as to ensure that the requirements remain applied, effective and correctly governed over time.

Continuous validation guarantees not only the execution of the defined controls, but also that the authority delegated to processes, contracts and technical mechanisms remains explicit, adequate and revocable.

⏳ 1. Suggested review periodicity​

Asset typeSuggested frequencyPrimary responsible
Critical applications (L3)Quarterly or per releaseAppSec + Application manager
L2 applicationsHalf-yearly or every 2 releasesAppSec + Dev Lead
External suppliersAnnually or per renewalProcurement + AppSec
Active contractsAnnually or per amendmentLegal + Functional manager

🔹 Frequencies must be adjusted on the basis of incidents, findings, changes of risk or relevant changes to automated processes that execute security validations, approvals or controls.

🔢 2. Items to validate per cycle​

Beyond the technical and contractual verification, each validation cycle must confirm that the governance assumptions remain valid:

  • Does the risk classification of the application or service still hold?
  • Do the requirements applied remain valid and effective?
  • Has any control stopped working (e.g. bypass, deactivation or silent change)?
  • Does the evidence remain accessible, legible and traceable?
  • Are there new exceptions or compensations to approve or renew?
  • Does the supplier continue to meet the agreed SLA and security requirements?
  • Are there automated processes or mechanisms that have started executing validations, blocks or approvals not previously framed in the defined governance model?
  • Does the delegation of execution to technical processes remain aligned with the assigned organisational authority?

🌎 3. Integration with tools​

The continuous validation process may be automated or supported by tools that allow consistent execution and traceable evidence, such as:

  • Jira (cyclical review tasks per application or contract);
  • SharePoint / Confluence (review forms or records);
  • Git (labels, issues or workflows per release);
  • SIEM or dashboards with findings and validation results.

💡 Preference should be given to tools that support an audit trail, change history and dated recording, making it possible to identify when automated processes were introduced, changed or deactivated.

📊 4. Example of an annual review plan​

Plan: Annual review of the contracts and integrations of the finance unit

Steps:

  1. Export the list of applications classified as L2/L3
  2. Validate for each one:
    • Requirements applied
    • Evidence of tests or validation
    • SBOM and supplier compliance
    • Active automated processes with an impact on security or governance
  3. Collect active exceptions, associated decisions and deadlines
  4. Report deviations, changes of authority and corrective actions

✅ Final recommendations​

  • Integrate reviews with the release cycle or with internal oversight mechanisms;
  • Create alerts for expired or non-revalidated exceptions;
  • Use this process to feed the governance KPIs (see kpis-governanca.md);
  • Treat recurring validation as an integral part of the security lifecycle;
  • Use continuous validation as a mechanism for detecting implicit delegations of authority to processes or systems, ensuring their review or revocation when necessary.

🔗 Cross-links​

  • Ch. 1 - Review of the risk classification (addon/15-aplicacao-lifecycle.md)
  • Ch. 2 - Requirements checklist per project
  • addon/03-modelo-validacao-fornecedores.md - Supplier onboarding and validation
  • addon/04-rastreabilidade-organizacional.md - Organisational traceability
  • addon/05-exemplos-praticos.md - Examples of decisions and exceptions