Risk Assessment Guidance
This guidance document establishes the official framework, metrics, and methodology for identifying, analyzing, evaluating, and treating information security risks across anDREa B.V. (anDREa). This framework forms a core component of our Information Security Management System (ISMS), structured to achieve strict compliance with ISO/IEC 27001:2023 (Clause 6.1.2 - Information Security Risk Assessment) and NIS 2 risk management guidelines.
1. Likelihood Classification
Likelihood defines the probability, frequency, or ease of exploitation associated with a specific threat event.
| Descriptor | Possible Frequency | Ease of Exploitation |
|---|---|---|
| Certain | Encompasses events that are expected to occur in most circumstances or repeat multiple times a year. 👉 Metric: > Once per week / Repeatedly. | Very Easy: Requires no specialized skills or technical resources. Exploits rely on publicly known vulnerabilities with readily available automated attack scripts. Minimal attacker effort required. |
| Likely | Encompasses events that will probably occur in most circumstances or at least once a year. 👉 Metric: Once per month to once per quarter. | Easy: Leverages commonly available security tools and techniques. Requires basic attacker skill sets; vulnerabilities are well-documented and exposed. |
| Possible | Encompasses events that might occur at some point. The threat has occurred elsewhere or is a recognized industry possibility. 👉 Metric: More than once per quarter to once per year. | Moderate: Requires specific knowledge, custom tools, or distinct exploits that are not widely distributed. May require a level of privileged access or specific target environment configurations. |
| Unknown | Undetermined or unassessed parameter. 👉 Metric: Not Known / Not Assessed. | Unknown / Not Assessed: Exploitability parameters cannot be determined due to insufficient diagnostic information. Typically applies to zero-day, novel, or poorly understood threats. |
| Rare | Highly unlikely to occur; events may materialize only within exceptional or extreme circumstances. 👉 Metric: Less than once per year. | Difficult / Very Difficult: Requires advanced, highly specialized skills, significant institutional resources, or a unique, complex combination of systemic factors to execute successfully. |
2. Impact Classification
Impact describes the absolute magnitude of harm or loss if a threat event occurs across seven distinct operational, technical, and corporate vectors.
| Descriptor | Confidentiality | Integrity | Availability | Financial | Reputation | Legal / Regulatory | Operational |
|---|---|---|---|---|---|---|---|
| High | Widespread disclosure of highly sensitive datasets (e.g., core trade secrets, platform-wide customer PII). | Critical system data is permanently corrupted or deleted; underlying system is rendered completely unusable. | Primary systems are offline for $>1$ week; operational standstill. | Financial loss exceeds €50,000 or directly threatens corporate solvency. | Irreparable brand damage; immediate loss of major corporate clients and market share. | Major criminal prosecution, significant regulatory fines, or revocation of operating licenses. | Complete cessation of critical business functions. |
| Medium | Contained disclosure of specific sensitive data blocks. | Important data assets are altered or modified, requiring significant internal effort to correct. | Key platforms are impaired or degraded for noticeable user disruption. | Financial loss falls between €10,000 and €50,000. | Negative regional or local media exposure; notable spike in formal client complaints. | Official regulatory warnings, audit non-compliances, or moderate monetary fines. | Moderate disruption to standard business operations. |
| Low | Limited disclosure of standard, non-sensitive data elements. | Minor data inaccuracies are introduced that are easily and quickly corrected. | Minor system slowdowns or localized lag; inconvenient but remains fully workable. | Financial loss falls between €1,000 and €10,000. | Minor internal friction or limited external negative feedback. | Minor technical breach observed; no formal regulatory action expected. | Minor inconvenience to daily operational tasks. |
| N/A | Negligible or zero data exposure. | Trivial data errors that are instantly fixed. | Negligible impact on overall system performance. | Financial loss is less than €1,000. | No discernible impact on brand trust or public reputation. | No discernible legal or regulatory impact. | Negligible impact on daily operations. |
3. Risk Level & Priority Determination
The Expert Assessment Paradigm
While standard risk management frameworks mechanically multiply likelihood by impact Likelihood x Impact, anDREa relies on Expert Security Assessments conducted by key internal stakeholders and external security advisors. This expert approach prevents systemic prioritization failures where mathematical modeling conflicts with real-world compliance duties and strategic targets.
Case Studies: Why $ ext{Likelihood} imes ext{Impact}$ Fails
- The Insider Threat Vector: Given the volume of global users operating under intense research pressure, the likelihood of an authorized user acting with malicious intent is Certain. Paired with a High potential impact, raw mathematical modeling would place this as an absolute top priority for engineering remediation. However, this risk is formally accepted as a baseline platform constraint under the Security Manifesto, as a platform cannot systematically block an authorized entity acting maliciously within their valid permissions.
- The Access Review Control: Because the myDRE platform mandates automated validation checks, the real-world likelihood of failing to execute Access Review Policy is Rare, and the immediate technical impact is Low. A multiplication matrix would score this as a negligible priority. However, anDREa explicitly classifies Access Review Policy as a Top Priority because it serves as our core technical control to unburden Tenants in demonstrating ongoing GDPR compliance.
4. Risk Acceptance Criteria & Priorities
Risk evaluation, tracking, and prioritization are performed periodically within the Information Security Management Board (ISMB) based on four baseline Priority Levels:
- High Priority (Unacceptable Risks): Risks within this band cannot be tolerated and require immediate treatment to drive them down to an acceptable level. If remediation is technically unfeasible, the risk can only be accepted via formal, documented authorization from senior management, accompanied by an explicit justification and a continuous monitoring plan. This exception must remain extremely rare.
- Medium Priority (Conditionally Acceptable Risks): Risks within this band are systematically reviewed. While mitigation is preferred, a Medium risk may be formally accepted if the cost of treatment is disproportionate to the potential impact, or if the exposure aligns directly with strategic business objectives. Acceptance requires documented approval from the designated Risk Owner, Department Head, or senior management.
- Low / No Priority (Acceptable Risks): These risks are tolerated without requiring dedicated mitigation projects. Low priority risks are managed and monitored via existing standard operating controls during regular risk cycle reviews, while No priority risks are openly tolerated.
Essential Acceptance Principles
- Cost-Benefit Constraints: Risk treatment decisions for Medium and High priorities must be justified via documented cost-benefit analyses of the proposed technical controls.
- Regulatory Compliance Floor: No risk can be accepted if it results in a breach of statutory, legal, regulatory, or contractual obligations. This restriction is absolute and cannot be overridden by internal management unless explicit legal exemptions apply.
- Appetite Alignment: All acceptance criteria thresholds are mapped directly to anDREa's master Risk Appetite Statement.
- Forensic Ledger Integrity: Every risk acceptance decision—including the underlying rationale, cost-benefit findings, and approving authorities—must be permanently documented, detailing the conditions for acceptance.
5. Post-Assessment Verification
Following the formal finalization of any Risk Assessment, MT must review the master Compliance and Risk Matrices. This step ensures that any newly identified threat vectors, modified risk levels, or newly deployed technical and organizational controls are accurately updated across our compliance blueprints.