IT Risk Identification practice questions

Threat intelligence feeds from ISACs

ISAC threat intelligence feeds provide sector-specific, curated data on active adversaries, tactics and emerging vulnerabilities, directly populating the risk universe with externally sourced IT threats. This breadth of current, industry-relevant information satisfies the stem's requirement for the best identification source, unlike internal-only inputs.

Timing and detection

The ISACA risk scenario template requires six elements: actor, threat type, event, asset, timing, and detection. Supplying only actor, threat type, event, and asset leaves timing and detection absent, so the scenario cannot express when the exfiltration occurs or how it would be discovered, weakening likelihood and impact assessment.

Categorize the risks

Categorising risks follows identification, grouping them by type, source or business area so that ownership and assessment can be assigned consistently. This satisfies ISACA's structured approach, where risks must be organised before analysis and evaluation, preventing duplication and ensuring each risk is subsequently assessed against the correct criteria.

IAST (Interactive Application Security Testing)

IAST instruments the running application, correlating runtime execution with source code to confirm which findings are genuinely reachable and exploitable, cutting false positives. That reachability evidence lets the firm rank vulnerabilities by real business risk rather than raw SAST and DAST volume.

Tampering

SQL injection modifies data or query logic within the database, which STRIDE classifies as Tampering: unauthorised alteration of data or code. Spoofing, Information Disclosure and Elevation of Privilege describe different outcomes, so Tampering is the threat type mapping directly to injection.

Operational risk

A software bug causing an outage disrupts service delivery and internal processes, which is the defining axis of operational risk. It arises from failed processes, people or systems rather than external market movements, so it belongs in this category.

Financial risk

An outage triggered by a software bug carries financial consequences: lost revenue, remediation costs and contractual penalties. Financial risk captures this monetary impact axis, distinct from the operational cause, so the same event legitimately spans both categories.

A disgruntled employee with excessive access privileges exfiltrates customer data to a competitor, resulting in a $2 million loss.

This scenario names the threat actor (disgruntled employee), the vector (excessive access privileges), the event (data exfiltration to a competitor) and a quantified business impact ($2 million loss), satisfying the ISACA requirement that scenarios connect realistic cause to measurable consequence.

Insufficient security awareness training for employees

Operational vulnerabilities stem from people, process and procedural weaknesses rather than technical flaws. Insufficient security awareness training is a human-factor gap that enables social engineering and credential theft, satisfying the question's requirement for an operational rather than technical vulnerability.

Lack of segregation of duties in financial systems

Segregation of duties is a control process ensuring no single person controls an entire financial transaction. Its absence is an operational vulnerability arising from inadequate process design, satisfying the question's requirement by exposing fraud and error risk through organisational rather than technical weaknesses.

TRIKE

TRIKE centres threat identification on the system's requirements and design, modelling risk from a requirements-driven perspective rather than asset or attacker libraries. This directly satisfies the stem's constraint of deriving threats from requirements and design, distinguishing it from approaches such as STRIDE or PASTA.

SAST

Static application security testing analyses source code without executing it, tracing untrusted input into SQL queries to flag injection flaws. SAST identifies SQL injection at the code level during development, making it the most likely source for discovering this newly identified web application vulnerability.

To document and manage identified risks throughout their lifecycle

Documenting and managing identified risks throughout their lifecycle fulfils the register's core function: it captures each risk's owner, likelihood, impact, response and status, then tracks changes as treatment progresses. This continuous recording satisfies the stem's demand for the primary purpose, since a register exists to maintain an auditable, current view of risk rather than to perform assessment itself.

Timing

Timing specifies when the threat event is expected to occur and the likelihood within a defined timeframe, exactly matching the stem's requirement. Threat actor, threat type, event and asset describe the who, what and target, but not the probability over a period.

ISACs

ISACs are sector-specific information sharing and analysis centres that collect and distribute actionable threat intelligence on attacks targeting cloud and industry infrastructure. They provide curated, relevant indicators and tactics, unlike generic vendor advisories or internal logs, satisfying the need for the best external source.

Strategic

Strategic risks, such as those arising from shifts in market demand or regulatory changes, are a standard IT risk category because they directly threaten the organisation’s long-term objectives and business model. In the stem, the practitioner must categorise risks in the risk register; strategic risks satisfy this requirement by representing a distinct, high-level category separate from operational, compliance, or financial risks.

Operational

Operational risk is a standard IT risk category covering failures in people, processes and day-to-day service delivery, including system outages and human error. It sits alongside strategic, compliance, financial and reputational categories in typical risk taxonomies used to populate a risk register.

VAST

VAST suits Agile and DevSecOps because it scales threat modelling across many small, fast-changing microservice teams, integrating lightweight, automated analysis into sprint workflows rather than requiring lengthy upfront design documentation. This satisfies the stem's constraint that techniques fit iterative Agile delivery.

STRIDE

STRIDE suits Agile and DevSecOps because its six threat categories (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) map directly onto per-story data-flow diagrams, letting teams threat-model incrementally each sprint without heavyweight documentation. This satisfies the stem's iterative-delivery constraint.

PASTA

PASTA suits Agile and DevSecOps because it is risk-centric and attacker-focused, aligning threat analysis with business objectives and producing prioritised findings that fit iterative sprints. This satisfies the stem's constraint that techniques integrate into Agile delivery rather than requiring a single upfront waterfall-style assessment.

Establishing risk tolerance thresholds for operational risk

Risk appetite defines how much risk the organisation will accept, so it directly drives the setting of risk tolerance thresholds that operational risks are measured against during identification. This translates the qualitative appetite statement into measurable boundaries for categorising and prioritising identified risks.

OSINT

OSINT aggregates publicly available data, including vendor blogs, forums, social media and government advisories, delivering near-real-time indicators of compromise and active threat activity. It satisfies the stem's real-time requirement because collection is continuous and unrestricted by classification or subscription barriers.

STRIDE

STRIDE is a classic threat modeling technique that categorizes threats for applications.

PASTA

PASTA is a risk-centric methodology that aligns with business impact.

Asset/resource

The asset affected (e.g., customer data) is a key element.

Consequence

Business impact is a required element.

Threat actor

The actor (e.g., external attacker) is a required element.

VAST

VAST (Visual, Agile, and Simple Threat) modelling was designed for integration into Agile and DevSecOps workflows, producing visual threat models that scale across teams. It satisfies the stem's requirement for a simple, visually oriented technique embedded in rapid development cycles.