Skip to main content

Minimum Controls Matrix by Risk Level

This matrix defines the minimum floor of security controls expected, by technical domain, according to the application's risk level (L1–L3), as determined in Chapter 01.

The controls listed here are a mandatory baseline for each risk level and must be understood as enforceable minimums, not as an upper limit of application.

The matrix can be used:

  • as an independent technical reference;
  • as a basis for release criteria;
  • as input for risk acceptance models;
  • as an instrument for control, audit or organisational KPIs.

🧠 Normative framing​

In Security by Design – Theory of Everything (SbD-ToE), the application's risk level determines the minimum degree of rigour expected in the application of security controls.

However:

  • the L1–L3 level results from a simplified projection of the risk (E/D/I model);
  • the attributes of the risk (detectability, evidentiability, reproducibility, delegation, real impact) may require additional reinforcement;
  • the absence of adequate evidence invalidates the effective application of the control, even if it is “planned”.

This matrix must therefore be applied together with:

  • the risk classification model;
  • the acceptance criteria;
  • the residual risk analysis;
  • and the risk lifecycle.

🛠️ Controls Matrix by Risk Level​

DomainLow Risk (L1)Medium Risk (L2)High Risk (L3)
Requirements (Ch. 2)ASVS N1 (adapted)ASVS N2 + formal criteriaASVS N2/N3 complete + validation by security
Threat Modelling (Ch. 3)Informal or omittedRegular collaborative sessionsFormal with DFDs + STRIDE and recording
Secure Architecture (Ch. 4)Minimum patternsTechnical review + trust zonesFormal review + mitigation documentation
Dependencies (Ch. 5)npm audit / dotnet listSCA with severity policyAutomated SCA + SBOM + alerts
Development (Ch. 6)Linters + basic reviewGuides + specific PR rulesMandatory review + reinforced secure review practices
CI/CD (Ch. 7)Protected credentialsValidation of environments and secretsProvenance, SLSA + integrity controls
IaC (Ch. 8)Manually reviewed scriptsScanners (e.g. tfsec)Formal policies + mandatory enforcement in the pipeline
Containers (Ch. 9)Trusted images + updatesHardening + image scanningSigning, formal policy, runtime protection
Security Testing (Ch. 10)Manual checklistsAd hoc SAST + DASTFuzzing, regression, continuous DAST
Secure Deployment (Ch. 11)Checklist + basic reversibilityDual approval + version controlFormal security validation process
Operations (Ch. 12)Local loggingBasic alerts + lightweight SIEMIntegration with IRP + real-time detection
Training (Ch. 13)Brief onboarding sessionAnnual training + practical sessionsFormal training + periodic assessments
Governance (Ch. 14)Simple security clausesTemplates with complianceRequirements by risk + validation before onboarding

⚠️ Mandatory control step-up rule​

⚠️ Essential normative note

Whenever the attributes of the risk indicate:

  • low detectability;
  • low evidentiability;
  • non-deterministic behaviour;
  • high delegation or automatic execution with real impact
    (including advanced automation or decision support),

controls equivalent to the next level up must be applied,
regardless of the L1–L3 classification initially assigned.

This rule applies to any technology or development practice and does not depend on the explicit presence of AI.

🔄 Updating and maintaining the matrix​

This matrix must be:

  • reviewed whenever relevant changes occur in the manual;
  • adjusted to the regulatory and organisational context;
  • kept consistent with internal security and risk policies.

Its use does not dispense with:

  • contextual analysis;
  • production of evidence;
  • formal recording of the decisions taken.

📌 Final note​

This matrix does not define “the maximum to do”,
it defines the acceptable minimum for each risk level.

Effective security results from the conscious, evidentiable and proportional application of controls -
not from mere compliance with a table.

🔗 Useful links​