← All policies

Risk Management Policy

1. Purpose

To establish a consistent methodology for identifying, assessing, treating, and monitoring information-security and privacy risks faced by the Company. The output of this process — the Risk Register — drives the prioritisation of controls, investments, and the Statement of Applicability.

2. Scope

All risks affecting the confidentiality, integrity, or availability of:

• Customer Personal Data;
• Cadences production systems and source code;
• the Company's contractual and regulatory obligations;
• the Company's reputation and operating continuity.

Excludes financial, market, and product-strategy risks unrelated to information security; those are managed separately.

3. Methodology

3.1 Risk identification triggers

Risks shall be identified at the following trigger points:

• Quarterly, at the periodic risk review.
• On material change: new sub-processor, new product feature processing personal data, new market segment, new regulator action, new customer contract type.
• After every SEV-1 or SEV-2 incident, as part of the post-mortem.
• On receipt of customer audit findings or compliance-platform alerts (Sprinto/Vanta).
• On vendor disclosure of relevant CVEs affecting the production stack.

3.2 Assessment

Each risk is rated on two axes using a 1–5 scale.

Likelihood (1 = Rare, 2 = Unlikely, 3 = Possible, 4 = Likely, 5 = Almost certain) — based on observed history, threat-intelligence, and inherent characteristics of the system.

Impact (1 = Negligible, 2 = Minor, 3 = Moderate, 4 = Major, 5 = Severe) — considering, in combination: harm to data subjects, regulatory penalty exposure, contractual liability, reputational damage, operational disruption.

The risk score is Likelihood × Impact (range 1–25), classified as:

3.3 Treatment options

Risks may be treated by:

• Avoiding the activity that creates the risk.
• Mitigating through controls that reduce likelihood, impact, or both.
• Transferring to a third party (e.g. cyber insurance, contractual indemnity).
• Accepting with documented rationale, including residual exposure and re-evaluation date.

3.4 Risk owner

Every risk has a single named owner who is accountable for the treatment decision and the operational follow-through. In the current one-person org, the Director is the default owner; on engaging additional personnel, owners are reassigned to align with role responsibilities.

3.5 Residual risk

After treatment, the residual risk is re-scored. Residual risks are accepted in writing by the Director (or, in future, by the role with the appropriate authority).

4. Risk register

The live state of all identified risks is maintained in the Risk Register. Each entry contains:

• Risk ID (e.g. R-001)
• Description (asset → threat → vulnerability → consequence)
• Inherent score (Likelihood × Impact, before controls)
• Existing controls
• Residual score (after controls)
• Treatment decision and target date
• Owner
• Last reviewed
• Next review

5. Review cadence

6. Linkage to other ISMS components

• Statement of Applicability: every Annex A control marked Applicable in the SoA traces to one or more risks.
• Audit programme: internal and external audits target highest-risk controls.
• Incident response: incidents that reveal an unmanaged risk update the register.
• Vendor management: sub-processor selection considers the risks in VMP-001.

7. Compliance and references

ISO/IEC 27001:2022 Clauses 6.1 (actions to address risks and opportunities), 6.1.2 (information-security risk assessment), 6.1.3 (information-security risk treatment), 8.2, 8.3.

ISO/IEC 27005:2022 Information security, cybersecurity and privacy protection — Guidance on managing information security risks (referenced for methodology).

GDPR Article 35 (data protection impact assessment) — DPIAs are conducted for high-risk processing as a specific subset of this methodology.

8. Version history