1. Document Information
| Field | Details |
|---|---|
| Organization | [Organization Name] |
| Assessment ID | [SRA-YYYY-XXX] |
| Assessment Date | [Date] |
| Assessment Scope | [ISMS / Department / Application / Process] |
| Assessment Period | [Period] |
| Assessment Owner | [Name / Role] |
| Risk Assessment Methodology | [Methodology Name / Version] |
| Approved By | [Name / Role] |
| Next Review Date | [Date] |
| Status | Draft / Approved / Closed |
2. Purpose
This Security Risk Assessment is used to identify, analyse, evaluate, and prioritize information security risks affecting the organization’s information assets, systems, processes, people, suppliers, and technology.
The assessment should help the organization determine:
- What needs protection?
- What could go wrong?
- What threats could cause harm?
- What vulnerabilities or weaknesses exist?
- What would be the impact?
- How likely is the risk?
- What controls already exist?
- What additional treatment is required?
- Who is responsible for the risk?
- What residual risk remains after treatment?
3. Assessment Scope
Clearly define what is being assessed.
Example
Organization: SaaS startup
Scope:
- Customer-facing SaaS application
- AWS production environment
- Corporate IT environment
- Employee endpoints
- Customer data
- Source code
- CI/CD environment
- Critical suppliers
- Security and compliance processes
The assessment should not automatically include every system in the organization.
The scope should correspond to the defined ISMS scope and the purpose of the assessment.
4. Risk Assessment Methodology
The organization should document the methodology used to determine and evaluate information security risks.
A practical example is:
Asset / Information
→ Threat / Risk Event
→ Vulnerability / Weakness
→ Impact
→ Likelihood
→ Risk Level
→ Risk Treatment
The organization should use a consistent methodology across assessments.
5. Likelihood Criteria
Example 5-point likelihood scale:
| Score | Likelihood | Description |
|---|---|---|
| 1 | Rare | Highly unlikely to occur |
| 2 | Unlikely | Could occur but is not expected |
| 3 | Possible | Could reasonably occur |
| 4 | Likely | Expected to occur in some circumstances |
| 5 | Almost Certain | Expected to occur frequently or is highly probable |
The organization should define its own criteria based on its environment.
6. Impact Criteria
Impact should consider the potential consequences to the organization.
| Score | Impact | Example |
|---|---|---|
| 1 | Insignificant | Minimal operational impact |
| 2 | Minor | Limited disruption or loss |
| 3 | Moderate | Noticeable business or security impact |
| 4 | Major | Significant business, customer, legal, or security impact |
| 5 | Severe | Critical business disruption, major data exposure, or significant regulatory/customer impact |
Impact may be assessed against:
- Confidentiality
- Integrity
- Availability
- Privacy
- Customers
- Regulatory obligations
- Financial impact
- Business continuity
- Reputation
7. Risk Calculation
A simple example is:
Risk Score = Likelihood × Impact
For example:
Likelihood = 4
Impact = 5
Risk Score = 4 × 5 = 20
Example risk bands:
| Score | Risk Level |
|---|---|
| 1–4 | Low |
| 5–9 | Medium |
| 10–15 | High |
| 16–25 | Critical |
These scoring bands are an example methodology, not a universal ISO 27001 requirement.
The organization should define and formally approve its own methodology and risk acceptance criteria.
8. Risk Identification
Each risk should be described in a way that clearly connects:
Threat → Vulnerability → Risk Event → Impact
Avoid vague statements such as:
“AWS security risk”
A more useful risk statement would be:
“A compromised privileged AWS credential could provide unauthorized access to production resources, potentially resulting in customer data exposure or disruption of the SaaS service.”
9. Security Risk Assessment Worksheet
| ID | Asset / Information | Process | Threat | Vulnerability / Weakness | Risk Event | Existing Controls | Likelihood | Impact | Initial Risk | Treatment | Risk Owner |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | AWS Production | IT Operations | Credential compromise | Excessive privileges | Unauthorized production access | MFA, IAM roles, logging | 4 | 5 | 20 | Reduce | CTO |
| R-002 | Customer Database | SaaS Operations | Unauthorized access | Misconfigured access | Customer data exposure | Encryption, IAM, monitoring | 4 | 5 | 20 | Reduce | Security Lead |
| R-003 | Source Code | Software Development | Account compromise | Weak access controls | Unauthorized code modification | MFA, RBAC, branch protection | 3 | 4 | 12 | Reduce | Engineering Lead |
| R-004 | Employee Laptop | Corporate IT | Malware | Phishing / outdated software | Endpoint compromise | EDR, awareness, patching | 3 | 4 | 12 | Reduce | IT Lead |
| R-005 | SaaS Application | Product | Exploitation | Application vulnerability | Application compromise | Secure SDLC, VAPT | 4 | 5 | 20 | Reduce | Engineering Lead |
10. Detailed Risk Assessment Record
Each significant risk should have a detailed assessment.
Risk ID
R-001
Asset / Information
AWS Production Environment
Business Process
SaaS Application Operations
Risk Owner
CTO
Threat
Compromise of privileged administrator credentials.
Vulnerability / Weakness
Potential excessive privileges, credential compromise, or inadequate access review.
Risk Event
An attacker obtains privileged credentials and gains unauthorized access to production AWS resources.
Potential Impact
- Customer data exposure
- Unauthorized system changes
- Service disruption
- Data modification or deletion
- Regulatory or contractual consequences
- Incident response costs
11. Existing Controls
Document controls that already exist before determining the additional treatment.
Example:
- MFA
- Role-based access control
- Least privilege
- Privileged access restrictions
- Quarterly access reviews
- CloudTrail logging
- Security monitoring
- Credential management
- Joiner/mover/leaver process
- Incident response process
Existing controls should be supported by evidence where possible.
12. Initial Risk
Likelihood
4 – Likely
Impact
5 – Severe
Initial Risk Score
4 × 5 = 20
Initial Risk Level
Critical
This represents the risk before considering additional treatment.
13. Risk Treatment
The organization should determine how each risk will be handled.
Possible options include:
Reduce
Implement or improve controls to reduce likelihood and/or impact.
Avoid
Stop the activity creating the unacceptable risk.
Share / Transfer
Transfer or share part of the risk through mechanisms such as insurance or contractual arrangements.
Accept
Accept the risk when it falls within approved risk acceptance criteria.
The selected treatment should be justified and approved where required.
14. Risk Treatment Plan
| Risk ID | Treatment Action | Control / Measure | Owner | Target Date | Status | Evidence |
|---|---|---|---|---|---|---|
| R-001 | Strengthen privileged access | MFA + least privilege + access review | CTO | [Date] | In Progress | IAM records |
| R-002 | Improve database access restrictions | IAM / network controls | Cloud Lead | [Date] | Open | Configuration |
| R-003 | Strengthen source-code security | MFA + branch protection | Engineering | [Date] | Closed | Git settings |
| R-004 | Improve endpoint protection | EDR + patching | IT | [Date] | In Progress | EDR reports |
15. Residual Risk Assessment
After treatment actions have been implemented, reassess the risk.
Example:
Initial Risk
Likelihood: 4
Impact: 5
Score: 20 – Critical
Treatment
- MFA enforced
- Privileged roles restricted
- Quarterly access review
- Cloud activity monitoring
- Administrative credentials protected
Residual Risk
Likelihood: 2
Impact: 5
Score: 10 – High
The impact may remain high because a successful compromise could still have significant consequences.
The treatment has primarily reduced the likelihood.
16. Residual Risk Decision
The organization should compare the residual risk with its approved risk acceptance criteria.
| Residual Risk | Within Acceptance Criteria? | Decision |
|---|---|---|
| Low | Yes | Accept |
| Medium | Depends on criteria | Accept / Further Treat |
| High | Depends on criteria | Further Treatment / Formal Acceptance |
| Critical | Normally requires further treatment or senior approval | Escalate |
The organization’s formally approved risk acceptance criteria should govern the final decision.
17. Risk Acceptance Record
Where residual risk is accepted, document:
| Field | Details |
|---|---|
| Risk ID | [R-XXX] |
| Risk Description | [Description] |
| Residual Risk | [Level / Score] |
| Reason for Acceptance | [Reason] |
| Existing Controls | [Controls] |
| Risk Owner | [Name / Role] |
| Approved By | [Name / Role] |
| Acceptance Date | [Date] |
| Review / Expiry Date | [Date] |
| Conditions | [If applicable] |
| Status | Accepted / Under Review |
Risk acceptance should be an informed business decision and should not simply be used to avoid remediation.
18. Risk Treatment Completion
Treatment should not be considered complete merely because an action has been assigned.
The organization should verify:
- Action was implemented.
- Control operates as intended.
- Evidence exists.
- Risk was reassessed.
- Residual risk was determined.
- Risk owner reviewed the result.
- Further treatment is or is not required.
19. Security Risk Assessment Summary
Management may receive a summary such as:
| Risk Level | Number of Risks | Trend | Action |
|---|---|---|---|
| Critical | 2 | ↓ | Immediate treatment |
| High | 7 | → | Treatment in progress |
| Medium | 12 | ↓ | Monitor / planned treatment |
| Low | 8 | → | Accept / monitor |
The summary should be based on the organization’s actual risk data.
20. Risk Assessment Triggers
A new or updated assessment should be considered when there are significant changes such as:
- New application
- New cloud environment
- New business process
- New customer requirements
- New supplier
- Major technology change
- Significant vulnerability
- Security incident
- Data breach
- Regulatory change
- New type of personal or sensitive information
- Organizational restructuring
- Major change in threat landscape
- Significant audit finding
Risk assessment should also be performed according to the organization’s defined review schedule.
21. Risk Assessment Evidence
Typical evidence includes:
- Approved risk methodology
- Risk assessment worksheets
- Risk Register
- Asset inventory
- Threat intelligence
- Vulnerability reports
- VAPT reports
- Security incident records
- Regulatory requirements
- Customer requirements
- Existing control evidence
- Risk Treatment Plan
- Risk acceptance approvals
- Residual risk assessments
- Management review records
22. Relationship With ISO 27001
The Security Risk Assessment supports the organization’s broader ISO 27001 risk management process.
The relationship can be represented as:
Business Context
↓
Assets / Information
↓
Threats & Vulnerabilities
↓
Risk Assessment
↓
Risk Evaluation
↓
Risk Treatment
↓
Necessary Controls
↓
Statement of Applicability
↓
Implementation
↓
Evidence & Effectiveness
↓
Residual Risk
↓
Continual Improvement
The organization should not select controls solely because they appear in Annex A. Controls should be determined through the organization’s risk treatment and applicable requirements, then compared with Annex A to help ensure necessary controls have not been overlooked.
23. Security Risk Assessment – Quick Template
A. Assessment Details
- Organization:
- Assessment ID:
- Date:
- Scope:
- Assessor:
- Risk Owner:
- Approved By:
B. Risk Identification
- Asset / Information:
- Business Process:
- Threat:
- Vulnerability:
- Risk Event:
- Potential Impact:
C. Existing Controls
- Preventive Controls:
- Detective Controls:
- Corrective Controls:
- Evidence:
D. Initial Risk
- Likelihood:
- Impact:
- Risk Score:
- Risk Level:
E. Treatment
- Treatment Option:
- Additional Controls:
- Action:
- Owner:
- Target Date:
- Status:
F. Residual Risk
- Likelihood:
- Impact:
- Residual Risk Score:
- Residual Risk Level:
- Acceptance Criteria:
- Further Treatment Required:
- Risk Acceptance Approval:
G. Review
- Review Date:
- Changes Since Previous Assessment:
- New Threats:
- New Vulnerabilities:
- Control Effectiveness:
- Further Action:
- Next Review Date:
24. Startup Example – Complete Assessment
Risk ID
R-007
Asset
Customer Database – AWS RDS
Threat
Unauthorized access through compromised credentials.
Vulnerability
Insufficient privileged access restrictions.
Risk Event
An attacker compromises a privileged account and accesses customer information stored in the production database.
Impact
Potential:
- Customer data exposure
- Privacy impact
- Customer notification
- Regulatory consequences
- Loss of customer trust
- Business disruption
Existing Controls
- MFA
- IAM
- Encryption at rest
- Network restrictions
- Logging
- Access reviews
Initial Assessment
Likelihood: 4
Impact: 5
Risk Score: 20
Risk Level: Critical
Treatment
- Enforce MFA for privileged users.
- Restrict database administrative access.
- Review privileged access quarterly.
- Monitor privileged activity.
- Remove unnecessary accounts.
- Strengthen credential management.
Residual Assessment
Likelihood: 2
Impact: 5
Residual Score: 10
Residual Risk: High
Decision
Compare the residual risk against the organization’s approved risk acceptance criteria.
If the risk remains above the organization’s acceptance threshold, additional treatment should be considered.
25. Common Mistakes
Avoid:
- Copying generic risks without considering the organization’s environment.
- Treating the risk register as a list of vulnerabilities.
- Selecting Annex A controls before performing risk assessment.
- Using a risk score without defining the methodology.
- Assigning risks without clear risk owners.
- Closing treatment actions without verifying effectiveness.
- Accepting risks without documented approval.
- Ignoring supplier and third-party risks.
- Failing to reassess risks after significant changes.
- Treating the spreadsheet as the objective rather than the decision-making process.
26. Final Checklist
| Activity | Complete |
|---|---|
| Scope defined | ☐ |
| Risk methodology approved | ☐ |
| Likelihood criteria defined | ☐ |
| Impact criteria defined | ☐ |
| Risk acceptance criteria defined | ☐ |
| Assets / information identified | ☐ |
| Threats identified | ☐ |
| Vulnerabilities identified | ☐ |
| Existing controls documented | ☐ |
| Initial risk assessed | ☐ |
| Risk treatment selected | ☐ |
| Risk owner assigned | ☐ |
| Treatment actions tracked | ☐ |
| Controls implemented | ☐ |
| Effectiveness verified | ☐ |
| Residual risk assessed | ☐ |
| Risk acceptance completed where applicable | ☐ |
| SoA implications considered | ☐ |
| Evidence retained | ☐ |
| Review date established | ☐ |
Final Principle
A useful Security Risk Assessment should answer:
What are we protecting? → What can go wrong? → How could it happen? → What would be the impact? → How likely is it? → What controls do we have? → What more should we do? → Who owns the risk? → What residual risk remains?
The assessment is successful when it leads to informed risk decisions and effective security treatment, not simply when a risk spreadsheet has been completed.