SEP3702 Integrated Security Risk Project Management Exam Notes (UNISA Study Guide)

Integrated Security Risk Project Management brings together two disciplines that are often taught separately but are inseparable in practice: security risk management and project management. In the context of South African higher education, especially modules such as UNISA SEP3702, students are expected to understand how security risks are identified, evaluated, treated, monitored, and communicated within the structured life cycle of a project. The strongest exam answers show not only theoretical knowledge, but also the ability to apply methods, frameworks, and decision-making logic to realistic security scenarios.

1. Core Concepts and Exam Orientation for SEP3702

1.1 What integrated security risk project management means

Integrated Security Risk Project Management refers to the coordinated application of project management principles and security risk management processes so that security objectives are planned, delivered, and sustained through the life of a project. The key word is integrated. Security is not treated as an afterthought, and project management is not treated as a purely administrative exercise. Instead, security requirements, threats, controls, compliance needs, stakeholder expectations, and operational constraints are built into the project from initiation to closure.

In practice, this means a project manager does more than schedule tasks and monitor budgets. The project manager must also consider:

Asset protection: what needs to be secured, and why.
Threat environment: who or what may cause harm.
Vulnerabilities: weaknesses that can be exploited.
Impact: what happens if the risk materialises.
Controls: how the project will reduce risk to an acceptable level.
Residual risk: the risk that remains after controls are applied.
Governance and compliance: legal, contractual, ethical, and organisational obligations.
Stakeholder trust: confidence that the project will deliver safely and responsibly.

A useful exam distinction is this: project management focuses on delivering a defined outcome within scope, time, cost, quality, risk, and stakeholder constraints; security risk management focuses on reducing uncertainty and harm related to security threats. When combined, the project becomes a controlled change process in which security is embedded in decisions, not patched on later.

1.2 Why this subject matters in South African project environments

South African organisations operate in a context where security risk is rarely abstract. Common realities include physical theft, insider threats, fraud, vandalism, cybercrime, service disruption, procurement irregularities, labour unrest, regulatory scrutiny, and reputational damage. A project that installs access control systems, deploys digital identity tools, builds transport infrastructure, or rolls out enterprise software will face security-related risks at every stage.

This is why SEP3702-type content is important for the South African environment:

Infrastructure projects may be exposed to theft of equipment, sabotage, or community protest.
IT and digital transformation projects face cyber risk, identity compromise, data leakage, and fraud.
Construction and facilities projects must manage site access, health and safety, materials security, and contractor control.
Public-sector projects often have strong compliance, transparency, and procurement requirements.
Private-sector projects are pressured by competition, uptime, confidentiality, brand protection, and shareholder accountability.

A project with poor security planning can experience delays, cost overruns, legal exposure, or total failure. For example, if a hospital upgrade project does not manage access to patient data and physical areas correctly, the organisation may face privacy breaches and operational disruption. If a banking system migration does not include identity and access controls, the project may create fraud opportunities or regulatory violations. In both cases, security risk management is not secondary; it is central to project success.

1.3 Typical exam expectations and how to answer well

Exams in integrated security risk project management usually test three levels of ability:

Recall of concepts
- Definitions of risk, threat, vulnerability, impact, control, mitigation, residual risk, stakeholder, governance, and project life cycle.
Explanation and comparison
- Difference between risk and issue, qualitative and quantitative risk analysis, preventive and detective controls, internal and external stakeholders, strategic and operational risks.
Application to scenarios
- Identifying risks in a project case study.
- Proposing appropriate controls.
- Ranking risks by likelihood and impact.
- Assigning responsibility and timing.
- Explaining how the project manager should communicate risks.

A strong exam answer should be structured, specific, and justified. A weak answer says, “The risk is theft, so add security.” A stronger answer says, “Because the project stores high-value equipment on an unsecured site, the likelihood of theft is moderate to high; the impact is schedule delay and budget variance. Appropriate controls include controlled access, inventory reconciliation, CCTV, physical barriers, and contractor vetting. Residual risk should be reviewed weekly during execution.”

1.4 Key terms that must be mastered

The following terms commonly appear across project and security risk discussions:

Term	Meaning	Exam importance
Risk	The effect of uncertainty on objectives	Central concept
Threat	A potential cause of harm	Used in identifying sources of risk
Vulnerability	A weakness that can be exploited	Explains why a threat matters
Impact	The consequence if the risk occurs	Supports prioritisation
Likelihood	The chance that a risk will occur	Part of risk scoring
Control	A measure that modifies risk	Used in treatment plans
Residual risk	Risk remaining after controls	Needed for realistic assessment
Risk appetite	Amount of risk an organisation is willing to accept	Guides decisions
Risk tolerance	Acceptable variation around objectives	Supports escalation decisions
Stakeholder	Any individual or group affected by the project	Vital for communication
Baseline	Approved project reference point	Used to detect deviations
Issue	A current problem requiring action	Different from a risk
Contingency	A planned response if a risk occurs	Supports resilience
Governance	Decision-making and accountability structure	Ensures oversight

1.5 Common mistakes students make

Many students lose marks because they confuse related concepts or give generic answers. Common mistakes include:

Treating all risks as negative only and ignoring the possibility of positive risk/opportunity.
Describing controls without explaining whether they are preventive, detective, corrective, or deterrent.
Using the words threat and risk interchangeably.
Listing risks without linking them to project objectives.
Failing to show how risk treatment affects scope, time, cost, quality, or stakeholder expectations.
Writing answers that are too general, such as “the project should have good security.”
Ignoring residual risk after controls are added.
Forgetting that risks change over the project life cycle.

A disciplined answer always connects the concept to the project objective. For example, a delayed security clearance process may increase the risk of missed milestones; inadequate data classification may increase the risk of data leakage; poor contractor screening may increase the risk of insider threat.

1.6 Exam framing tip: the “objective-risk-control” chain

A practical way to structure answers is to use the chain:

Objective: What is the project trying to achieve?
Risk: What could prevent or damage that objective?
Cause: Why might the risk occur?
Impact: What would happen if it occurs?
Control: What action reduces the likelihood or impact?
Residual risk: What remains after treatment?
Owner: Who is responsible?

Example:

Objective: Deliver a new access control system by 30 September.
Risk: Delayed delivery of biometric hardware.
Cause: Supplier stock shortages and import delays.
Impact: Installation slips, testing is shortened, and the go-live date is missed.
Control: Dual sourcing, buffer stock, early procurement, contract penalties, and progress tracking.
Residual risk: Moderate, because import disruption cannot be eliminated entirely.
Owner: Procurement manager and project manager jointly.

This chain is highly useful in essay answers because it shows analytical depth and professional logic.

2. Security Risk Management in the Project Life Cycle

2.1 Initiation: security requirements begin before planning

The initiation phase determines whether the project is worth doing and whether it can be delivered responsibly. In security-sensitive projects, initiation must identify the business need, the security context, the stakeholder environment, and the high-level risks. A poor initiation phase creates hidden threats that later become expensive problems.

At initiation, the project manager and sponsor should ask:

What assets or information will the project affect?
Which laws, regulations, standards, or policies apply?
What security incidents could derail the project?
Which stakeholders could be harmed by poor security?
Does the project need formal approvals, licences, vetting, or compliance checks?
Is the project aligned with organisational risk appetite?

A strong initiation document often includes a preliminary security risk statement. For example, “The project will handle confidential student records and therefore requires data protection controls, access restrictions, and audit logging.” This is much better than leaving security to be discovered later.

At this stage, the project charter should define:

purpose and objectives,
scope boundaries,
high-level assumptions,
major constraints,
initial risk summary,
sponsor authority,
governance structure.

If security risks are not acknowledged in the charter, the project team may underestimate the time, cost, and resources required to deliver safely.

2.2 Planning: the point where risk becomes actionable

Planning is where integrated security risk management becomes systematic. The team identifies risks, analyses them, prioritises them, and decides how to respond. Planning should also integrate risk thinking into scope, schedule, procurement, quality, communications, human resources, and stakeholder management.

Important planning outputs include:

Risk management plan
Risk register
Security requirements specification
Control selection and implementation plan
Communication and escalation matrix
Change management approach
Procurement and supplier security criteria
Incident response and contingency plans

Risk identification methods

Useful techniques include:

brainstorming,
interviews,
document reviews,
lessons learned from previous projects,
SWOT analysis,
checklists,
Delphi technique,
expert workshops,
site inspections,
security assessments,
threat modeling.

A good exam answer may name the method and explain why it fits the scenario. For example, in a project involving a new data centre, site inspections and expert workshops may be more useful than generic brainstorming because physical layout, access routes, environmental resilience, and infrastructure dependencies are critical.

Risk analysis and prioritisation

Risk analysis evaluates likelihood and impact. A common qualitative matrix uses categories such as low, medium, and high, or scores from 1 to 5. If likelihood is scored 4 and impact 5, the resulting risk rating may be 20 on a 25-point scale, which indicates high priority.

A simple matrix is shown below:

Likelihood	Impact	Example rating	Priority
Low	Low	1–4	Monitor
Low	High	5–9	Plan response
Medium	Medium	10–12	Active management
High	High	15–25	Immediate action

The exact scale may vary by organisation, but the logic remains the same: high-likelihood, high-impact risks demand urgent attention.

Risk response options

The main response strategies are:

Avoid: change the plan to eliminate the risk.
Reduce/Mitigate: take action to lower likelihood or impact.
Transfer/Share: move some effect to another party, often through insurance or contracts.
Accept: acknowledge the risk and monitor it, usually when it is below threshold or response cost is too high.

In security projects, “transfer” must be used carefully. You can transfer financial exposure through insurance, but you cannot fully transfer accountability for poor governance. A contractor may install controls, but the organisation still owns the risk environment.

2.3 Execution: controls must be implemented, not merely approved

During execution, plans become reality. This is often where security projects fail, because controls approved on paper are not properly deployed. Execution requires coordination among project staff, vendors, users, security specialists, and sponsors.

Key execution responsibilities include:

implementing physical and logical controls,
enforcing access permissions,
conducting awareness training,
managing supplier performance,
monitoring incidents and near misses,
verifying that controls work as intended,
updating the risk register when conditions change,
escalating unresolved issues.

A frequent exam insight is that controls are only effective if they are operationalised. For instance, a policy that says “all contractors must sign in” is not sufficient unless the sign-in process is monitored, logs are retained, and noncompliance is enforced.

Execution also requires integration with quality management. If a security control is installed but not tested, it should not be considered complete. For example, a CCTV system that powers on but does not cover blind spots or store footage for the required period does not meaningfully reduce risk.

2.4 Monitoring and controlling: risk is dynamic

Security risk is never static. New threats emerge, assumptions change, contractors delay delivery, and users behave unexpectedly. Monitoring and controlling are therefore continuous activities, not end-of-project checks.

The project manager should track:

changes in likelihood and impact,
control effectiveness,
milestone slippage,
issue escalation,
residual risk levels,
compliance status,
budget variance related to security controls,
stakeholder concerns,
incident trends.

Useful monitoring tools include:

risk reviews,
dashboard reporting,
audit logs,
variance analysis,
site inspections,
test results,
exception reports,
lessons-learned logs.

When a security-related issue occurs, the project team must decide whether it is a known risk event or a new issue requiring immediate action. For example, if the supplier misses a delivery date that was already identified as a risk, the team activates contingency actions. If a new vulnerability is found in the system architecture, that may be a new issue requiring urgent reassessment.

2.5 Closure: security does not end when the project ends

Project closure is not just administration. It includes validation that deliverables meet requirements, handover to operations, documentation of lessons learned, and confirmation that security controls remain owned after the project team disbands.

At closure, the team should:

confirm that all planned security controls are in place or formally accepted,
hand over assets, documents, and responsibilities,
close open risks or transfer them to operations,
archive security records,
document incidents and responses,
review whether residual risks are acceptable.

A common mistake is assuming that once a project is completed, security ownership disappears. In reality, many risks become operational risks after handover. A well-managed closure ensures continuity of control and accountability.

3. Risk Identification, Analysis, and Treatment in Security Projects

3.1 Building a comprehensive risk register

The risk register is one of the most important tools in SEP3702-type project work. It is a living document that records identified risks, their descriptions, causes, impacts, likelihoods, ratings, owners, treatment actions, deadlines, and status. A risk register is valuable because it makes uncertainty visible and manageable.

A well-designed register usually includes:

risk ID,
risk description,
root cause,
affected objective,
likelihood rating,
impact rating,
overall risk score,
current controls,
planned responses,
owner,
due date,
status,
residual risk,
comments and updates.

Example structure:

ID	Risk	Cause	Impact	Likelihood	Score	Response	Owner
R1	Theft of hardware	Unsecured storage area	Delay and cost overrun	4	16	Mitigate	Site manager
R2	Data leakage	Weak access controls	Privacy breach	5	25	Reduce	IT security lead
R3	Contractor noncompliance	Poor vetting	Insider threat	3	12	Reduce	Procurement manager

The register should not be static. It must be reviewed regularly and updated whenever a new risk is found, a control changes, or a risk materialises.

3.2 Differentiating threats, vulnerabilities, impacts, and controls

Students often get higher marks when they show clear conceptual separation.

Threat

A threat is a possible source of harm. Examples include criminals, dishonest employees, equipment failure, natural disasters, or cyber attackers.

Vulnerability

A vulnerability is the weakness that allows the threat to succeed. Examples include poor password policy, unsecured perimeter fencing, lack of segregation of duties, or inadequate vendor screening.

Impact

The impact is the damage caused if the event occurs. This may include financial loss, delay, legal penalties, reputational damage, safety incidents, or service outage.

Control

A control is a measure that reduces risk. Controls may be technical, physical, administrative, or human-behaviour based.

A precise exam answer may look like this:

Threat: external theft.
Vulnerability: materials stored in a lightly guarded area.
Impact: replacement cost and construction delay.
Control: fencing, security guards, inventory tracking, and lighting.

This format shows strong analytical discipline.

3.3 Qualitative and quantitative analysis

Qualitative analysis

Qualitative analysis uses descriptive categories and expert judgment. It is often faster and more practical in early project phases. A risk matrix is usually enough when data is limited.

Advantages:

simple to use,
quick to apply,
understandable to stakeholders,
useful for prioritisation.

Limitations:

can be subjective,
may oversimplify complex risks,
depends on expert opinion.

Quantitative analysis

Quantitative analysis uses numerical estimates to estimate the effect of risk. Common techniques include:

expected monetary value,
sensitivity analysis,
decision trees,
Monte Carlo simulation,
cost-benefit analysis.

Quantitative methods are helpful when risks have measurable cost consequences. For example, if a one-week delay in a project costs R85,000 in labour and overheads, and the probability of a delay is 30%, then the expected monetary exposure from that risk is:

R85,000 × 0.30 = R25,500

This does not mean the risk will cost exactly R25,500. It means that over many similar projects, the average expected exposure is that amount. Quantitative analysis is especially powerful when you must justify spending on controls.

When to use each

Use qualitative analysis for early screening and broad prioritisation.
Use quantitative analysis when costs are material, the data is strong, or the decision is high stakes.

A strong exam answer should mention that both methods may be combined. An initial qualitative screen can identify the top ten risks, and quantitative analysis can then evaluate the most expensive or sensitive ones.

3.4 Risk treatment strategies in depth

Avoidance

Avoidance means changing the project plan so the risk no longer exists. Example: selecting a different supplier to avoid a politically unstable region. This is appropriate when the risk is severe and the project can still meet its objectives without the exposed option.

Mitigation

Mitigation reduces likelihood or impact. Example: adding firewall rules, security guards, backup generators, training, or redundant suppliers. Mitigation is the most common strategy in integrated security projects because it allows the project to proceed while lowering exposure.

Transfer

Transfer shifts the financial consequences to another party. Insurance is the classic example. Contractual clauses can also allocate responsibility. However, transfer is never complete in a governance sense; the organisation still has to manage the work, verify performance, and accept residual exposure.

Acceptance

Acceptance is appropriate when the risk is minor, the treatment cost is too high, or the organisation is willing to tolerate the exposure. Acceptance should be conscious, documented, and approved, not accidental.

3.5 Selecting controls: preventive, detective, corrective, and deterrent

A mature exam response often classifies controls by function.

Control type	Purpose	Example
Preventive	Stop an event before it occurs	Access cards, firewalls, pre-employment screening
Detective	Identify an event after it occurs	CCTV monitoring, audit logs, intrusion detection
Corrective	Reduce damage after an event	Backups, incident response, restoration procedures
Deterrent	Discourage malicious behaviour	Warning signage, visible guards, disciplinary policy

Effective projects combine these categories. For example, a secure warehouse may use fencing and locks as preventive controls, motion sensors as detective controls, backup stock as corrective control, and warning signs as deterrent control.

3.6 Residual risk and risk appetite

Every project has residual risk after controls are applied. No control eliminates uncertainty entirely. The key question is whether the residual risk falls within the organisation’s risk appetite and risk tolerance.

Risk appetite is the level of risk the organisation is willing to pursue or retain.
Risk tolerance is the acceptable deviation around project objectives.

If residual risk remains above tolerance, additional action is needed. If it is within tolerance, formal acceptance may be justified. This distinction is frequently tested because it links technical assessment to managerial decision-making.

A useful exam line is: controls reduce risk, but governance determines whether the remaining risk is acceptable.

4. Governance, Stakeholders, Communication, and Ethics

4.1 Governance structures in integrated security projects

Governance is the framework through which decisions are made, monitored, and enforced. In security risk project management, governance ensures that security is not left to informal judgment. Instead, responsibilities are clear, escalation paths exist, and accountability is traceable.

Typical governance structures include:

Project sponsor: approves scope, funding, and major decisions.
Project manager: coordinates delivery and manages daily project performance.
Security manager or security specialist: advises on controls, risks, and compliance.
Steering committee: oversees direction, approves changes, resolves escalations.
Risk owner: person accountable for a specific risk.
Functional managers: support resources, standards, and operational alignment.

In an exam scenario, it is important to show that governance is not merely administrative. It is a control mechanism. If there is no clear governance, security decisions may be inconsistent, delayed, or politically influenced.

4.2 Stakeholder analysis and why it matters

Security projects affect many stakeholders, and stakeholders can either support or undermine the project. A stakeholder is any person or group who can influence the project or be affected by it.

Typical stakeholders include:

sponsor,
users,
security staff,
IT department,
facilities team,
contractors,
regulators,
customers,
communities,
senior management,
auditors.

A useful way to analyse stakeholders is to consider:

power,
interest,
attitude,
influence,
information needs.

For example, a regulator may have high power and high interest but little day-to-day involvement. A user group may have lower formal power but high interest and strong practical influence if they resist new controls. A contractor may have time-limited involvement but high operational impact during implementation.

A stakeholder matrix can help:

Stakeholder	Power	Interest	Key concern	Communication need
Sponsor	High	High	Benefits, budget, delivery	Weekly summary
Users	Medium	High	Usability, access, workflow	Training and feedback
Security team	High	High	Control effectiveness	Detailed risk reports
Contractors	Medium	Medium	Scope, deadlines, access	Clear instructions
Regulators	High	Medium	Compliance	Formal evidence

4.3 Communication as a control mechanism

Communication in security risk projects is not only about reporting progress; it is also a risk control. Poor communication can produce misunderstandings, delayed action, and unsafe behaviour. Effective communication ensures that the right people know the right things at the right time.

Key communication principles:

Timeliness: report before issues become crises.
Accuracy: use verified information.
Clarity: avoid ambiguous language.
Audience fit: adapt detail to stakeholder needs.
Consistency: keep messages aligned across teams.
Confidentiality: protect sensitive security information.

For example, it may be inappropriate to circulate detailed vulnerability data to all stakeholders. The project manager must balance transparency with security. This is especially important in cyber and physical security projects, where over-disclosure may create additional risk.

Communication channels may include:

risk reviews,
steering committee meetings,
progress reports,
exception reports,
dashboards,
escalation emails,
formal change requests,
incident notifications.

4.4 Ethics and responsible decision-making

Ethics is central to security risk management because the field deals with power, surveillance, privacy, access, and harm prevention. A technically effective control may still be ethically problematic if it is intrusive, discriminatory, or unlawful.

Ethical project management requires:

respect for privacy,
proportionality of controls,
fairness in access and screening,
honesty in reporting,
responsible use of monitoring,
avoidance of bribery, favouritism, and corruption,
truthful representation of risk and progress.

Consider a project that introduces facial recognition at a workplace. Even if technically feasible, ethical questions arise about privacy, consent, data retention, bias, and misuse. A strong answer would recognise that ethical review is part of risk governance, not a separate afterthought.

4.5 Legal and compliance considerations

Security projects often intersect with law and regulation. In South Africa, the relevant environment may include organisational policies, contractual obligations, labour requirements, information governance rules, and sector-specific compliance duties. The exact legal framework depends on the project, but the principle is the same: non-compliance is itself a project risk.

Compliance risks can arise from:

poor data handling,
unlawful surveillance,
weak procurement processes,
inadequate records management,
unsafe site conditions,
failure to obtain approvals,
contract breaches,
missing audit evidence.

The exam usually rewards answers that show compliance as a project constraint and risk driver. For example, if a project handles personal information, the team must plan for lawful processing, secure storage, authorised access, and controlled disclosure. If construction work is involved, the team must manage site security, contractor conduct, and safety requirements.

4.6 Incident escalation and decision authority

Not every event should be handled at the same level. One of the strongest governance skills is knowing when to escalate.

Escalation should occur when:

impact exceeds tolerance,
the event affects key milestones,
the risk threatens legal compliance,
the issue requires resources beyond the project team,
multiple departments are affected,
there is potential for reputational damage.

A useful escalation logic is:

identify the incident or risk trigger,
assess immediate impact,
implement short-term containment,
notify the correct decision-maker,
document the event,
update the risk register,
monitor follow-up actions.

Clear escalation rules help prevent confusion and delays during security incidents.

5. Exam Application, Problem Solving, and Revision Frameworks

5.1 How to answer case study questions

Security project exam questions often present a scenario and ask for risks, controls, stakeholders, or governance recommendations. High-mark answers are analytical, not descriptive. They identify what is happening, why it matters, and what should be done.

A strong structure is:

Identify the issue
Explain the risk
Link it to the project objective
Recommend a control or response
State the expected result
Mention residual risk or follow-up

Example:

Scenario: A university is implementing a biometric access system for laboratories, but installation is delayed because contractors cannot enter the site on schedule.

Answer:

The risk is schedule delay caused by poor contractor access coordination.
The impact is late installation, shortened testing, and possible launch delay.
Controls include advance access scheduling, site induction, contractor permits, and a daily coordination log.
The project manager should escalate if delays affect the critical path.
Residual risk remains if supplier availability is uncertain, so a contingency buffer should be maintained.

This approach is concise yet complete.

5.2 Common project scenarios and model thinking

Scenario 1: Physical security upgrade

A building security upgrade may involve CCTV, fencing, alarm systems, and access control. Risks include poor integration, equipment theft, power outages, and user resistance. The project manager should prioritise testing, supplier quality checks, and backup power.

Scenario 2: Information security implementation

A digital security project may involve identity management, encryption, and monitoring tools. Risks include misconfiguration, delayed training, data migration errors, and privacy concerns. Mitigation includes phased deployment, testing, role-based access, and audit trails.

Scenario 3: Public-sector infrastructure project

A public project may face procurement delays, community protest, corruption exposure, and material theft. Controls include transparent procurement, stakeholder engagement, contractor screening, and site security planning.

Scenario 4: Hybrid workplace security project

A hybrid work project may combine physical and cyber controls. Risks include unsecured remote access, device loss, and weak user awareness. Controls include endpoint protection, VPN policy, MFA, and awareness training.

5.3 Writing high-quality risk analysis answers

To score well on risk analysis questions, use precise language and avoid vague generalities.

Weak:

“The risk is that security may fail.”
“The project should be more secure.”
“They should monitor the project.”

Strong:

“The risk is unauthorised access to the server room due to inadequate badge control and tailgating.”
“Mitigation should include anti-tailgating controls, access logs, visitor escort procedures, and periodic access review.”
“Monitoring should include weekly audit checks and incident trend analysis.”

Specificity demonstrates understanding. It also shows that you can connect theory to practical measures.

5.4 Revision checklist for the final exam

Use the following checklist when revising SEP3702:

Can you define risk, threat, vulnerability, impact, control, residual risk, and risk appetite?
Can you explain the difference between project risk and security risk?
Can you describe the project life cycle and where risk management fits in each phase?
Can you identify stakeholders and explain their influence?
Can you distinguish preventive, detective, corrective, and deterrent controls?
Can you explain qualitative vs quantitative analysis?
Can you construct or interpret a risk register?
Can you explain escalation, governance, and decision authority?
Can you apply risk treatment strategies: avoid, mitigate, transfer, accept?
Can you write answers that link risks to scope, schedule, cost, quality, and compliance?

5.5 Mnemonic-style memory aid for exam writing

A practical memory sequence for answering scenario questions is:

O-C-I-C-R-O

Objective
Cause
Impact
Control
Residual risk
Owner

If you can explain each part clearly, you usually produce a strong exam answer. This keeps your writing analytical and ensures you do not stop at naming risks without closing the loop.

5.6 Final synthesis: what the marker is looking for

Markers typically reward students who show that security risk management is:

systematic rather than ad hoc,
integrated rather than isolated,
documented rather than assumed,
continuous rather than one-time,
balanced between security, cost, time, and usability,
governed through accountability and escalation.

In other words, the best answer demonstrates that you understand the project as a controlled change initiative in a real environment with competing objectives. A successful project does not remove all risk; it manages risk intelligently so that objectives can be achieved safely, legally, and sustainably.

Security risk project management is therefore not only about protection. It is about enabling delivery with confidence. That is the central insight behind SEP3702-style study material: projects succeed when security is built into every phase, every decision, and every stakeholder interaction.