Information & Cyber Security: GRC and Risk Management

This course builds on foundational information security governance, risk, and compliance (GRC) concepts to focus specifically on performing risk assessments throughout the business lifecycle. It covers why and how to assess information and cybersecurity risk, how to build business impact assessments (BIAs) using a service-oriented approach, and how to determine the likelihood of compromise based on controls, so that a risk assessment can communicate clear, actionable messages to executives. The material uses a running scenario throughout: Globomantics Airport, which is undertaking a cloud migration program covering three representative systems — a public customer information website, an HR system, and an aviation/luggage screening system — hosted (in whole or in part) by two candidate cloud service providers, AeroStream and NovaNest.

Table of Contents

• Module 1: Introducing Information Security Risk Assessments
  • Thinking Like an Attacker
  • Attacker Economics and Risk Management
• Module 2: Common Procedures and Objectives for Risk Assessments
  • The Big Picture and the Risk Assessment Grid
  • Building a Risk Impact Matrix
  • Case Study: Website Unavailable
  • Case Study: HR Data Breach
  • Case Study: Loss of Integrity in Luggage Screening
  • From Impact to Likelihood: Common Risk Assessment Outcomes
• Module 3: Building a Business Impact Assessment
  • Know Your Business: A Service-Oriented Approach
  • Recovery Time Objective (RTO)
  • Recovery Point Objective (RPO)
  • Modeling a Service-Oriented Business: The Cloud Migration Example
  • Know Your Data
  • Know Your Technology Operations
• Module 4: Building Risk Scenarios and Assessing Likelihood
  • Gathering Information: Industry and Education Sources
  • Gathering Information: Standards and Internal Company Data
  • Categorizing Controls
  • Likelihood of Compromise and Defense in Depth
  • Analyzing the Attack Surface
  • Building a Controls Environment: A Worked Example
  • Controls Assessment and Determining the Final Likelihood
• Module 5: Business Lifecycle and Risk
  • A High-Level View of the Business Lifecycle
  • Risk Assessments in the Early Stages of the Lifecycle
  • Risk Assessments in the Later Stages of the Lifecycle
  • Risk Maturity and Human Factors
  • Increasing Confidence in Risk Assessments: The Johari Window
• Summary

Module 1: Introducing Information Security Risk Assessments

Thinking Like an Attacker

A recurring question that a GRC function must be able to answer is: do we need a risk assessment? The underlying mission statement of any information/cyber security function is straightforward: prevent undesirable disruption to the organization’s mission. Out of the many questions that GRC must answer, risk assessment focuses primarily on the first two:

1. What information security do we need?
2. How much of it do we need?

Answering these requires a structured way to understand what can lead to an undesirable disruption event and how likely that is to occur. Risk treatment (what you actually do about an assessed risk) is a related but separate topic.

To understand risk, it helps to deliberately flip perspective and think like an attacker or adversary, not a protector or defender. Not everyone needs access to all information — some of it must remain confidential. This produces three classic security requirements, each of which an attacker can attack in different ways:

These three properties are not independent:

• A loss of availability can cause a loss of integrity (data becomes stale/inaccurate because it could not be updated in time).
• A loss of confidentiality can lead to a loss of availability (systems may need to be taken offline for forensic investigation and incident response).

flowchart LR
    A[Confidentiality Breach] -->|forces takedown for forensics| C[Availability Loss]
    C -->|data goes stale| B[Integrity Loss]
    B -->|attacker also seeks unauthorized access| A

Threats successfully cause a breach of confidentiality, integrity, or availability by exploiting vulnerabilities. Whether a threat is realized as an actual attack depends on two main factors: motivation (desire) and capability (ability). Reviewing current threat intelligence is essential to keep this picture up to date — attacker capability, in particular, tends to increase over time because of the commoditization of attack tooling, sometimes called Cybercrime-as-a-Service.

Attacker Economics and Risk Management

Attackers are subject to the same economic logic that defenders are. An attacker must weigh:

• The cost of an attack (tools, tactics, and procedures needed to exploit available vulnerabilities).
• The potential repercussions if caught.
• Against the opportunity and potential value of a successful attack.

This gives defenders a powerful lens: if we understand attacker economics, we can better answer how likely is a threat to successfully exploit a vulnerability and affect the CIA of an asset? Likewise, understanding impact helps infer attacker motivation — if something is valuable to your organization, it is probably also an attractive target for an attacker.

Risk treatment’s real goal is to disrupt attacker economics enough that the attacker’s cost outweighs their expected reward. This does not hold uniformly for every attack type — phishing, for example, is extremely low cost for the attacker regardless of target-specific controls — but it is a useful general principle for prioritizing investment.

A key economic optimization is collaborating with other risk subject-matter experts (SMEs) across risk domains (safety, operational, financial, etc.) so that a single control can simultaneously mitigate multiple types of risk — maximizing “bang for the buck.” For example, data backups mitigate system failure, environmental disaster, and accidental threats, as well as malicious threats such as ransomware — which strengthens the business case for the control.

flowchart TD
    Backups[Data Backup Control] --> Sys[Mitigates: System/Hardware Failure]
    Backups --> Env[Mitigates: Environmental/Accidental Threats]
    Backups --> Mal[Mitigates: Malicious Threats e.g. Ransomware]

Non-malicious threats (system, environmental, accidental) are generally out of scope for a cyber security risk assessment specifically, but they usually remain in scope for a broader information security risk assessment (which covers CIA generally), because they can create conditions in which vulnerabilities are more easily exploited — for example, a power outage disabling physical security controls, allowing an opportunistic attacker to simply walk in and take what is lying around.

Module 2: Common Procedures and Objectives for Risk Assessments

The Big Picture and the Risk Assessment Grid

The procedures and objectives common to virtually all risk assessments (not just information security ones) do not have to be performed in a strict linear order — in practice, many are worked in parallel. Two benchmarks anchor the whole exercise:

• Risk appetite — the amount of risk an organization is willing to accept in pursuit of its objectives.
• Risk tolerance — the acceptable variation around that appetite, including for a specified period of time.

This course focuses mainly on qualitative risk assessments, as this is what most organizations use in practice.

Almost every risk assessment report includes some version of a 2D risk grid (likelihood × impact), because it is the visual language executives already understand and hold the budget for:

quadrantChart
    title Risk Assessment Grid
    x-axis Low Impact --> High Impact
    y-axis Low Likelihood --> High Likelihood
    quadrant-1 Outside Risk Appetite
    quadrant-2 Monitor Closely
    quadrant-3 Within Appetite
    quadrant-4 Tolerable (Time-bound)

The x-axis (impact) requires a way to understand how a business can be impacted — this is the foundation for the business impact assessment (BIA), covered in Module 3. To make the impact scale meaningful, organizations build a risk impact matrix, which provides the context needed to answer the “so what?” of any risk conversation.

Building a Risk Impact Matrix

The categories that make up an impact matrix are not necessarily ranked, with one exception: safety should always be considered first. Even where the residual safety risk is low, virtually every organization has humans at its core — customers, employees, or the public — and there are usually legal/regulatory obligations tied to safety. The following categories recur across most impact matrices:

Key principle: when reviewing potential impact, all categories must be considered together holistically — the final overall impact rating can be derived in different ways depending on organizational risk culture (e.g., take the highest rating across categories for a risk-averse culture, the rating that aligns to the least tolerable risk appetite, or simply the most common rating across categories).

Case Study: Website Unavailable

Scenario: The Globomantics customer information website (public flight arrivals/departures, airport layout, shop and operations status) becomes unavailable.

Overall rating chosen: Very Low (the most common rating across categories, appropriate since this does not impact critical airport operations). Practical implication: the organization can be comfortable migrating this website to a public cloud.

Case Study: HR Data Breach

Scenario: A data breach exposes home addresses, social security numbers, and salary data from the HR system.

Practical implication: significantly more caution is warranted migrating and operating the HR system in the cloud than the public website, due to the potential impact of an HR data confidentiality loss.

Case Study: Loss of Integrity in Luggage Screening

Scenario: The integrity of the airport’s luggage/aviation security screening system is compromised — staff can no longer trust what the system is telling them, and they cannot tell when the tampering began.

Key lesson — context changes the worst case: if the same system instead suffered an accidental technical fault rather than a malicious integrity compromise, and it happened outside operating hours and could be fixed before reopening, the assessed impact would likely be materially lower. Always assess the specific scenario, not just the asset in the abstract.

From Impact to Likelihood: Common Risk Assessment Outcomes

Having assessed impact for the three example systems, the next step is determining likelihood. A naive “worst case” assumption (almost certain compromise in all three cases) is rarely realistic — organizations typically migrate to the cloud partly because it can offer better resilience, provided controls are implemented properly.

Inherent risk is the risk in the context of a decision not to treat the risk any further. It is commonly (but imprecisely) described as “the risk with no controls” — in reality, some controls almost always already exist, either inherent to the environment or as a byproduct of external law/regulation (“Government” with a big G). For third-party/cloud hosting, the CSP’s baseline control environment directly shapes what counts as “inherent” risk for the customer.

Worked comparison — choosing between two CSPs (inherent risk perspective):

In this example, AeroStream provides a head start over NovaNest simply due to its baseline (inherent) control environment — evaluating a CSP’s controls is a core part of third-party risk management. Regardless of which CSP is chosen, the objective is always to reduce likelihood as low as reasonably possible (ALARP), balanced against economic feasibility.

Other risk treatment options surface naturally from this analysis:

• Avoid — e.g., choose not to migrate a system to the cloud at all (which itself requires a separate risk assessment of the status quo, which may show no easy way to reduce the existing likelihood/impact either).
• Phase delivery (“path to green”) — accept that risk cannot be reduced to the target level in phase 1, but plan to close the gap in phase 2. This introduces the concept of residual risk, covered in later modules.

flowchart LR
    Inherent[Inherent Risk] -->|Apply Controls| Residual1[Residual Risk - Phase 1]
    Residual1 -->|Additional Controls in Phase 2| Residual2[Residual Risk - Phase 2 'Path to Green']

Four important considerations to carry forward:

1. Inherent risk is contextual, not “zero controls.” There is almost always some baseline control (environmental, or externally mandated by law/regulation).
2. Information security risk does not exist in isolation. Organizational risk appetite and competing priorities may mean a cloud migration proceeds even when an information security risk assessment flags high risk (discussed further in Module 5).
3. A risk impact matrix is not an incident prioritization matrix. It does not capture the urgency signals needed during an active incident (that requires separate, incident-specific data points) — but it remains essential once there is time to do considered post-incident impact analysis.
4. Absolute measures of likelihood are inherently difficult, especially for information/cyber security risk, because past incidents are not a reliable predictor of future performance. However, a shift to relative risk comparison (e.g., CSP A vs. CSP B) is still highly useful for decision-making.

Module 3: Building a Business Impact Assessment

Know Your Business: A Service-Oriented Approach

Building a business impact assessment (BIA) requires understanding four areas in the context of a risk assessment:

1. Business
2. Data
3. Technology operations
4. Third parties (acknowledged as a large topic in its own right, only touched on here)

Rather than assessing the three example systems in isolation (as in Module 2), this module models them through the lens of business services — what each system actually does for the business:

This is called a service-oriented approach, and it is the underlying principle behind regulations such as the EU’s Digital Operational Resilience Act (DORA) — a standard that other regulators are expected to increasingly follow worldwide. A core aim of such regulation is ensuring that in-scope businesses correctly identify their important business services.

Recovery Time Objective (RTO)

Operational resilience is a broader discipline than information/cyber security, but shares essential concepts that materially improve BIA quality. A loss of confidentiality or integrity often also causes a loss of availability (a system may need to be taken offline to investigate or because it can no longer be trusted) — so the higher the business impact, the stricter the recovery requirements must be.

Recovery Time Objective (RTO): how soon a system/service must be restored to its pre-incident operational state after a disruption (e.g., a successful cyber attack). Every business service must have a defined RTO, driven by business need to prevent/mitigate impact — and RTOs can be context-dependent (e.g., time of day, operational period), so should be reviewed regularly.

timeline
    title Recovery Time Objective (RTO) Timeline
    Normal Operation : Service running (green)
    Disruption Event : Successful cyber attack — service becomes unavailable
    RTO Window : Time allowed to restore service to pre-incident state
    Recovery Complete : Service restored — RTO met (or breached)

Example RTOs from the case study:

Note the distinction: this is the RTO for the service being unavailable. Preventing and detecting compromise itself must operate continuously (24/7), independent of the RTO clock.

Recovery Point Objective (RPO)

Recovery Point Objective (RPO): the maximum tolerable amount of data loss, measured as a length of time between the last good backup and the disruption event. It complements RTO as part of incident management/recovery planning, with the business acknowledging that some data loss may be acceptable within risk appetite. Every business service that depends on data must have a defined RPO, generally based on how much manual effort would be required to reconstruct lost data.

timeline
    title Recovery Point Objective (RPO) Timeline
    Last Good Backup : Known good data state
    Data Loss Window : Data created/changed here may be unrecoverable (bounded by RPO)
    Disruption Event : Ransomware attack — service and data affected
    Recovery : Restore from last good backup — data within RPO is lost

Example RPOs from the case study:

Modeling a Service-Oriented Business: The Cloud Migration Example

A cloud service provider (CSP) typically exposes a catalog of services. In practice, one technology service often serves another before eventually reaching a business service — and business services can, in turn, impact each other.

Globomantics service dependency model:

flowchart BT
    DB[AeroStream: Database Service] --> AppHost[Airport IT: Application Hosting Technology Service]
    AI[AeroStream: AI Service] --> AppHost
    AppHost --> Portal[Customer Information Portal Service]
    AppHost --> Luggage[Luggage Screening System]
    Luggage --> Aviation[Aviation Security Service]
    DB2[AeroStream: Database Service - 2nd Instance] --> Payroll[NovaNest: Payroll Service - SaaS]
    Payroll --> HR[HR System / Services]

Working backwards (upstream) through RTOs:

This exercise demonstrates why existing BIAs should not be taken at face value — validating (and correcting) previously documented RTOs/RPOs against the actual service dependency model is itself one of the objectives of performing a BIA.

Real-Time Actual (RTA): the RTO achieved during actual recovery testing (as opposed to the target objective). In the case study, a measured RTA of 30 minutes comfortably beats the < 1 hour RTO and stays within risk appetite.

Impact tolerance (DORA concept): an additional metric required under DORA for important business services — those fundamental to society, the economy, or law and order — specifying the point at which disruption would cause catastrophic, widespread consequences. This ties directly into likelihood and residual risk analysis (Module 4).

Know Your Data

Three general categories of data relevant to a BIA:

Typical data classification labels (illustrative — organizations vary):

Data mapping across the case study systems:

Every system in the case study holds systems-data secrets (credentials, passwords, session tokens) — an attacker target regardless of the system’s business purpose. Highly restricted data (regulated PII or sensitive aviation security data) is present across nearly every service given how interconnected they are, directly informing the level of confidentiality-loss impact and the control strength required.

Know Your Technology Operations

The underlying technology stack that must be understood for a BIA spans multiple layers:

flowchart TD
    Infra[Infrastructure: buildings, networking/connectivity, hardware/bare-metal servers] --> DataLayer[Databases & Repositories: libraries, packages]
    DataLayer --> Apps[Applications, APIs, Platforms]
    Apps --> MW[Middleware]
    MW --> Endpoints[Endpoints: laptops, mobile, tablets]
    Procs[Processes, Procedures, Workflows e.g. password reset] -.cross-cutting.-> Infra
    Procs -.-> DataLayer
    Procs -.-> Apps
    Procs -.-> Endpoints
    Interfaces[Interfaces & Endpoints for maintenance/updates] -.spans all layers.-> Infra

Outsourcing any part (or all) of this stack to a third party is common precisely because managing every layer directly is difficult. A shared responsibility model applies for cloud services: the CSP is responsible for the security of the cloud, while the customer remains responsible for what it puts in the cloud — but accountability for the outcome always remains with the customer, regardless of what has been outsourced.

Ways impact can be distributed across the tech stack (explored further in Module 4):

1. Between your own service operations.
2. Between your organization and other customers of the same CSP (e.g., shared AeroStream database service instances).
3. Across shared/common components spun up and torn down across different environments (dev/test/prod), which cloud technology makes especially easy.

Every configuration choice creates a particular state for the tech stack, and complexity inevitably introduces flaws and vulnerabilities — holes an attacker may try to exploit to compromise the dependent services. This sets up the transition to likelihood analysis in Module 4.

Module 4: Building Risk Scenarios and Assessing Likelihood

Gathering Information: Industry and Education Sources

To determine realistic risk scenarios and their likelihood, look to several external sources:

Gathering Information: Standards and Internal Company Data

A good standard should be a clear, unambiguous document providing best-practice advice, developed by subject-matter experts under a governance body that manages due diligence and protects against commercial/political pressure on the content. Standards matter for risk scenario building because they encode controls for the most common risk scenarios — you can effectively “reverse-engineer” a standard’s baseline controls to infer which risk scenarios it is designed to treat.

Example: PCI-DSS is nominally scoped to card payment data, but its baseline protections (based on observed common threats and general security hygiene) make it broadly useful and one of the stronger standards for general-purpose control guidance.

Internal sources of risk information:

Categorizing Controls

ISO/IEC 27002:2022 describes several control attributes that can be used to categorize controls, useful for structuring a discussion of likelihood:

The standard also explicitly allows organizations to define custom attributes suited to their own risk context — the next section develops one such custom lens: likelihood based on control layering.

Likelihood of Compromise and Defense in Depth

Working hypothesis: the organization is being deliberately targeted. Likelihood is assessed by examining how well-controlled each layer of the attack path is.

1. Endpoints & external interfaces — the attack surface reachable via the internet or exposed to human error:

Endpoints are the human/computer interface, and humans remain susceptible to mistakes and social engineering (phishing remains one of the most cost-effective attack vectors for an attacker). Realistically, likelihood at this layer can only reach Unlikely when there genuinely are no endpoints/interfaces at all — and even then, watch for admin portals used by third parties for infrequent maintenance, accidental network/firewall misconfiguration, and shadow IT.

2. Trust boundaries — internal firewalls/switches, network segmentation, cloud account segregation, virtual private clouds:

• No boundary controls: still almost certain (no meaningful change).
• Following the same maturity curve (incomplete → partial → full coverage) reduces likelihood further than relying on endpoint controls alone.
• Boundary controls matter because of shared risk distribution / blast radius — e.g., could the website be an entry point for lateral movement to the application hosting service, then to luggage screening → aviation security, or to the AI service? Are two database service instances (used by different downstream customers) properly segregated from each other?

3. End-to-end controls — e.g., end-to-end encryption — provide a further reduction in likelihood on top of endpoint and boundary controls.

flowchart LR
    subgraph Layer1[Endpoint & Interface Controls]
        E1[No Controls: Almost Certain] --> E2[Incomplete Coverage: Very Probable] --> E3[Full Coverage, Partially Effective: Probable] --> E4[Fully Effective: Possible]
    end
    subgraph Layer2[Trust Boundary Controls]
        B1[No Boundaries: Almost Certain] --> B2[Incomplete: Very Probable] --> B3[Partial: Probable/Possible] --> B4[Fully Effective: Possible/Unlikely]
    end
    subgraph Layer3[End-to-End Controls]
        Enc[End-to-End Encryption] --> Reduced[Likelihood Further Reduced]
    end
    Layer1 --> Layer2 --> Layer3

This layered reduction in likelihood as more independent control layers are added is the practical expression of defense in depth.

Analyzing the Attack Surface

Attack surface analysis builds directly on the “Know Your Technology Operations” work from Module 3. Asset management (per ISO/IEC 27002) is a key control here — it is extremely difficult to secure what you don’t know you have.

Three factors that shape attack surface and control coverage:

Controls are themselves part of the attack surface. Distributed control-plane messages, patch-management systems that push updates to every endpoint, and the asset register itself are all potential attacker targets — an asset register combined with vulnerability data would save an attacker significant reconnaissance effort. Controls are typically accessible via endpoints, must be configured, and can themselves contain flaws and vulnerabilities.

Building a Controls Environment: A Worked Example

Scenario: what is the likelihood of an attacker gaining unauthorized access to the luggage screening service?

Step 1 — Trace a plausible attack path (identify faults):

sequenceDiagram
    participant Attacker
    participant AdminCreds as Admin Credentials
    participant Portal as Customer Information Portal
    participant FileShare as Luggage Screening File Share
    participant SIEM
    participant DB as Database Service

    Attacker->>AdminCreds: Obtain via Post-it note / phishing / social media OSINT
    Attacker->>Portal: Exploit vulnerability (alternative path)
    Portal->>FileShare: Lateral movement to admin password on file share
    Attacker->>FileShare: Retrieve stored admin password
    Attacker->>SIEM: Eavesdrop for more credentials / exploit vulnerability
    Attacker->>SIEM: Switch off security alerts
    Attacker->>DB: Alter configuration undetected
    Attacker->>DB: Delete data, including backups

Step 2 — Apply controls to break the chain:

flowchart TD
    A[Attacker Targets Admin Credentials] -->|MFA + Training + Spam Filter + Social Media Policy| A2[Credential Theft Mitigated]
    A2 -->|Encryption| A3[Credentials at Rest/Transit Protected]
    A3 -->|Firewalls + Patching| A4[Lateral Movement Restricted]
    A4 -->|Two-Person Auth + Segmented Control Plane| A5[SIEM Tampering Mitigated]
    A5 -->|Off-CSP / On-Prem Backup Copy| A6[Backup Destruction Mitigated]
    A6 -->|Behavioral Monitoring vs Known-Good State| A7[Residual Anomalies Detected]

Controls Assessment and Determining the Final Likelihood

Sources for choosing appropriate controls:

Choosing a control is not the end of the story — controls must be:

1. Implemented correctly, following standards’ best-practice guidance, with the right people involved.
2. Assessed for design suitability against the threat and risk appetite (e.g., is it proportionate to spend $100K protecting a service with a $20K financial impact?).
3. Assessed for operating effectiveness — e.g., a detective control that collects logs is only as good as whether anyone actually reviews those logs. Gaps in design or operation both mean a control is only partially effective.
4. Validated through controls assurance before go-live (e.g., penetration testing) and continuously monitored afterward — often formalized as Risk and Control Self-Assessments (RCSAs).

Important caveat on the “deliberately targeted” hypothesis: likelihood analysis assumes deliberate targeting to enable use of threat intelligence and attacker-economics reasoning, but organizations must also account for collateral damage (being incidentally affected because a shared CSP is targeted for unrelated reasons) and opportunistic/unsophisticated random attacks.

Bringing it together — final likelihood outcome for the luggage screening scenario:

Net result: likelihood is reduced from Very Probable down to Possible through layered, even if only partially effective, controls.

Module 5: Business Lifecycle and Risk

A High-Level View of the Business Lifecycle

flowchart LR
    BigBang[Big Bang: Business/Org Formed] --> Discovery[Discovery: Understand Problem, Objectives, Requirements incl. Security]
    Discovery --> BizCase[Business Case Approved & Financials Signed Off]
    BizCase --> Design[Solution Architecture Design incl. NFRs]
    Design --> Build[Build & Test vs Acceptance Criteria e.g. Code Scanning]
    Build -->|Issues Found| Design
    Build --> Deploy[Deployment & QA e.g. External Pen Test]
    Deploy --> ORR[Operational Readiness Review incl. Incident Playbooks]
    ORR -->|Go/No-Go| GoLive[Go Live]
    GoLive --> Warranty[Warranty Period / Hypercare]
    Warranty --> BAU[Business as Usual]
    BAU --> Exit[Exit: Decommission / Exit Activity or Third Party]

Two broad categories of business change trigger this lifecycle:

1. Internal changes — often organized as a transformation program changing ways of working.
2. External-facing changes — how the business creates profit or meets a societal need.

Both proceed through the same subsequent steps once a business case is approved:

• Solution architecture — the designed solution (procedural, technical, or both) demonstrating how approved requirements are met. Information security requirements typically fall under non-functional requirements (NFRs), unless security itself is the product/service being delivered.
• Build & test — validated against acceptance criteria (e.g., security code scanning); issues found here frequently require revisiting the solution architecture, especially in agile delivery.
• Deployment & QA — may include an external penetration test.
• Operational readiness review (ORR) — a stage-gate decision on whether to go live, checking that the solution both meets requirements and can be operated and managed safely (e.g., incident response playbooks are in place).
• Between go-live and steady-state operation, two scenarios are common: (1) something goes badly wrong with no option to fix forward, forcing a stop or rollback; (2) a warranty period, particularly with third-party delivery involvement, where the vendor remains engaged to support any post-go-live issues.
• Business as usual (BAU) does not truly begin until there is confidence the change has been delivered successfully and the business can stand on its own.
• Eventually, the business (or part of it) exits an activity, decommissions technology, or exits a third-party relationship.

Risk Assessments in the Early Stages of the Lifecycle

Two complementary approaches to risk assessment recur throughout the lifecycle:

• Top-down — start from potential business impact of a disruption event (as used for the three case-study systems in Module 2).
• Bottom-up — start from the technology stack and work upward, layering on controls (as used in the attack surface analysis in Module 4).

flowchart TD
    TD["Top-Down: Business Impact → Services → Technology"] -.combined with.-> BU["Bottom-Up: Technology Stack → Controls → Services"]
    TD --> Inherent[Full Picture of Inherent Risk]
    BU --> Inherent

Ideal early-stage state: a baseline top-down risk assessment of the business combined with a threat analysis exercise — sometimes there simply isn’t enough information yet for a bottom-up assessment. This may even form part of building the organization’s enterprise risk management framework and risk appetite that subsequent assessments align to.

• Inherent risk assessments are performed top-down for new products or large change programs (as with the airport cloud migration), but the full picture of inherent risk requires combining this with the bottom-up “Know Your Technology Operations” impact assessment.
• Good change-risk practice: avoid making bottom-up changes to the most impactful business areas first, where that can be avoided.

Warning — delivery risk vs. operational risk: program/portfolio/project managers are often focused primarily on delivery risk (missed milestones, scope, budget) — tracked via project risk logs — rather than inherent operational risk (e.g., sensitive data used insecurely in a dev environment). This is a natural consequence of their incentive structure (near-term delivery objectives, far-off production consequences), not negligence — and once a delivery manager’s objectives are met, responsibility for lingering risk is often handed off to operations or another team.

Risk Assessments in the Later Stages of the Lifecycle

Residual risk and the migration timeline: the stage of a program affects the residual risk assessment. Early in a cloud migration, the organization may lack operational skills to run cloud workloads (especially incident handling), and reputational concerns about a poor first change may lead to avoiding residual risk (delaying the change, ideally with well-communicated contingency time built in). Later in the program, more controls are in place and more operational experience has been gained, so the organization may be more willing to accept residual risk. A third-party delivery partner providing a managed service can transfer responsibility for a period (though never accountability). Finally, the organization might choose to reduce the risk directly — e.g., restrict a new AI-enabled luggage screening system to internal flights only, excluding international flights, until confidence is higher.

Real businesses are rarely this linear — there will be many overlapping mini- and micro-lifecycles, internal interdependencies, and external factors shaping how business lifecycles evolve, and risk assessment practice needs to remain flexible accordingly.

Risk Maturity and Human Factors

Three human factors materially affect risk assessment quality:

Increasing Confidence in Risk Assessments: The Johari Window

A useful framework for understanding — and being transparent about — the confidence level of a risk assessment is the Johari window, adapted here to risk knowledge:

quadrantChart
    title Risk Knowledge - Johari Window
    x-axis Unknown to Others --> Known to Others/Industry
    y-axis Unknown to Us --> Known to Us
    quadrant-1 Known Knowns
    quadrant-2 Unknown Knowns
    quadrant-3 Known Unknowns
    quadrant-4 Unknown Unknowns

A risk assessment is fundamentally the exercise of moving knowledge between these boxes toward “known knowns” — while recognizing this can never be fully realized. Being transparent about the proportion of risk knowledge sitting in each box is itself part of good risk communication.

An important, counter-intuitive message to prepare executives for: as risk assessment knowledge and maturity improve, a sequence of assessments may show risk appearing to get worse — not because the underlying situation is actually deteriorating, but because assessment quality has improved and previously hidden risk is now visible. (The reverse — hiding a genuinely worsening risk behind the pretense of “just better data” — is not acceptable practice.)

A related quality signal: repeatability. If a different set of SMEs and risk professionals performed the same assessment, would they reach the same conclusion? Following a consistent, standards-aligned method promotes repeatability and increases confidence in the outcome — and transparency around both the assessment and subsequent treatment decisions helps minimize negative impact from residual uncertainty.

Summary

This course walked through a complete, practical approach to performing information and cybersecurity risk assessments across a business lifecycle, using a running cloud-migration case study (Globomantics Airport, AeroStream, and NovaNest).

Key principles:

• Think like an attacker: risk assessment starts from understanding how confidentiality, integrity, and availability can be compromised, and why an attacker would want to compromise them.
• Attacker economics is a two-way street — risk treatment succeeds when it tips the cost/reward balance against the attacker, and controls chosen to serve multiple risk domains at once maximize value.
• Nearly all risk assessments share common building blocks: a 2D risk grid, a risk impact matrix (safety, financial, reputational, regulatory), and a documented risk appetite/tolerance to benchmark against.
• Impact assessment is built from a service-oriented Business Impact Assessment (BIA): know your business, your data, your technology operations, and (briefly) your third parties — expressed through RTOs, RPOs, and (for important business services) impact tolerance.
• Likelihood assessment is built from understanding information sources (industry, standards, internal MI), categorizing controls, analyzing the attack surface, and applying defense-in-depth layering (endpoint → boundary → end-to-end) to move likelihood down the scale from almost certain toward unlikely.
• Risk assessment approach (top-down vs. bottom-up) should match the stage of the business lifecycle — from initial discovery, through design/build/test, to go-live, BAU, and eventual exit.
• Human factors (delivery pressure, overconfidence, confirmation bias) and honest self-assessment of risk knowledge (the Johari window: known knowns, known unknowns, unknown knowns, unknown unknowns) both materially affect the quality and credibility of a risk assessment.

Quick-reference: Likelihood scale used throughout (defense-in-depth maturity)

Risk assessment checklist:

• Confirm organizational risk appetite and risk tolerance as benchmarks before starting.
• Build/validate the risk impact matrix across safety, financial, reputational, and regulatory categories, considered holistically.
• Model the business as services, not just isolated systems — trace dependencies upstream and downstream.
• Define/validate RTO, RPO, and (where relevant) impact tolerance for every business service.
• Classify data by type (business, corporate, systems) and sensitivity (public through highly restricted).
• Map the technology stack and attack surface (size, distribution, volume) underpinning each service.
• Gather threat and control intelligence from ISACs, standards, vendors, national agencies, and internal MI (risk register, incident reports, board papers).
• Assess likelihood using layered defense-in-depth reasoning, verifying that controls are correctly designed and operating effectively.
• Match the assessment approach (top-down / bottom-up / combined) to the current business lifecycle stage.
• Be transparent about assessment confidence and known gaps (Johari window) when communicating results to executives.

Search Terms

information · cyber · security · grc · risk · management · governance · compliance · networking · systems · assessments · business · assessment · lifecycle · likelihood · case · controls · data · impact · know · study · attacker · gathering · objective