Understand how information security risks influence the selection, implementation, and monitoring of ISO 27001 controls.
Risk assessment is one of the foundations of an effective ISO/IEC 27001 Information Security Management System (ISMS). ISO 27001 does not expect an organization to implement every security control simply because it appears in Annex A. Instead, organizations identify their information security risks, evaluate those risks, and select appropriate controls to reduce them to an acceptable level.
For startups and growing companies, this risk-based approach helps ensure that security investments are focused on the risks that matter most to the business.
1. What Is Risk Assessment in ISO 27001?
An ISO 27001 risk assessment is a structured process for identifying information security risks, analyzing their potential impact and likelihood, and determining how those risks should be treated.
A simple way to understand it is:
Assets → Threats → Vulnerabilities → Risk → Treatment → Controls → Monitoring
For example:
A SaaS company stores customer data in a cloud database.
A compromised administrator account could provide unauthorized access to that database.
The resulting risk may include data exposure, customer impact, regulatory consequences, and reputational damage.
The organization then determines whether the risk is acceptable and, if not, what controls or other treatments are necessary.
2. Why Is Risk Assessment Important?
Risk assessment helps management answer three fundamental questions:
What can go wrong?
Identify threats, vulnerabilities, weaknesses, and situations that could affect information security.
How serious would it be?
Evaluate the potential consequences and likelihood of the risk occurring.
What should we do about it?
Determine whether to reduce, avoid, transfer, or accept the risk.
This prevents organizations from implementing security controls randomly or simply copying another company’s ISMS.
3. ISO 27001’s Risk-Based Approach
ISO 27001 requires organizations to establish and apply an information security risk assessment process.
The organization should define:
- How risks will be identified
- How risks will be analyzed
- How likelihood will be evaluated
- How impact will be evaluated
- How risks will be scored or categorized
- What constitutes acceptable risk
- Who is responsible for assessing and approving risks
- How frequently risks will be reviewed
- How changes will trigger reassessment
The exact methodology can differ between organizations.
There is no single mandatory ISO 27001 risk scoring formula that every organization must use.
For example, an organization may use:
Risk Score = Likelihood × Impact
with a scale such as 1–5.
Another organization may use qualitative categories such as:
- Low
- Medium
- High
- Critical
What matters is that the methodology is defined, consistently applied, and appropriate for the organization’s context.
4. Step 1 – Establish the Context
Before assessing risks, understand the organization’s environment.
Consider:
Internal factors
- Business model
- Technology architecture
- Organizational structure
- Employees and contractors
- Existing security controls
- Critical applications
- Internal processes
- Information assets
External factors
- Customers
- Suppliers
- Regulators
- Legal requirements
- Industry requirements
- Cybersecurity threats
- Market conditions
- Geographic considerations
For example, a fintech company may face different information security risks from a small marketing agency.
5. Step 2 – Identify Information Assets
Identify the information and supporting assets that need protection.
Examples include:
| Asset | Example |
|---|---|
| Customer information | Names, contact details, account information |
| Financial information | Invoices, payment information |
| Source code | Git repositories |
| Credentials | Passwords, API keys, tokens |
| Cloud infrastructure | AWS, Azure, GCP environments |
| Applications | SaaS platform, ERP, CRM |
| Employee information | HR records |
| Contracts | Customer and supplier agreements |
| Security information | Logs, vulnerability reports |
| Intellectual property | Product designs and business information |
Do not limit the assessment only to IT systems.
People, processes, physical locations, suppliers, and information can also be relevant to information security risk.
6. Step 3 – Identify Threats and Vulnerabilities
Once important assets are identified, consider what could compromise them.
Common threats
- Phishing
- Malware
- Ransomware
- Insider misuse
- Credential theft
- Account compromise
- Data leakage
- Supply-chain attacks
- Denial-of-service attacks
- Physical theft
- Unauthorized access
- Cloud misconfiguration
Common vulnerabilities
- Weak passwords
- Excessive privileges
- Missing security patches
- Poor access reviews
- Lack of encryption
- Insecure application configuration
- Insufficient monitoring
- Weak supplier controls
- Lack of backup testing
- Inadequate security awareness
A threat does not automatically represent a risk.
The organization should consider how a threat could exploit a vulnerability and affect a relevant asset or business process.
7. Step 4 – Analyze the Risk
Risk analysis normally considers two primary factors:
Likelihood
How likely is the risk to occur?
Example scale:
| Score | Likelihood |
|---|---|
| 1 | Rare |
| 2 | Unlikely |
| 3 | Possible |
| 4 | Likely |
| 5 | Almost Certain |
Impact
What would happen if the risk occurred?
Impact may consider:
- Confidentiality
- Integrity
- Availability
- Financial loss
- Legal or regulatory consequences
- Customer impact
- Operational disruption
- Reputation
- Contractual consequences
Example:
| Score | Impact |
|---|---|
| 1 | Insignificant |
| 2 | Minor |
| 3 | Moderate |
| 4 | Major |
| 5 | Severe |
8. Example Risk Calculation
Suppose a company identifies this risk:
Risk: Unauthorized access to production database.
Likelihood = 4
Impact = 5
Using a simple methodology:
Risk Score = 4 × 5 = 20
The organization may define 16–25 as a high-risk category.
The result would therefore require management attention and an appropriate risk treatment.
The scoring thresholds are organization-specific and should be defined in the organization’s risk assessment methodology.
9. Step 5 – Compare Risk With Risk Acceptance Criteria
Not every risk requires immediate elimination.
Organizations normally establish a risk acceptance criteria.
For example:
| Risk Score | Category | Example Treatment |
|---|---|---|
| 1–4 | Low | Accept / monitor |
| 5–9 | Medium | Consider treatment |
| 10–15 | High | Treatment normally required |
| 16–25 | Critical | Immediate management attention |
These ranges are only an example.
Your organization should establish thresholds that reflect its own business, regulatory obligations, risk appetite, and operating environment.
10. Step 6 – Treat the Risk
ISO 27001 risk treatment can generally involve several approaches.
1. Modify the risk
Implement controls or other measures to reduce the likelihood or impact.
Example:
Implement MFA for privileged accounts.
2. Avoid the risk
Stop the activity that creates the unacceptable risk.
Example:
Discontinue an insecure legacy application that is no longer required.
3. Share or transfer the risk
Transfer part of the risk to another party through appropriate contractual, insurance, or service arrangements.
Example:
Use a specialized cloud service provider with defined security responsibilities and contractual commitments.
Risk transfer does not necessarily eliminate the organization’s accountability.
4. Retain or accept the risk
Management may consciously accept a risk when it falls within the organization’s risk acceptance criteria.
The acceptance should be documented and authorized appropriately.
11. How Risk Assessment Influences ISO 27001 Controls
This is one of the most important concepts in ISO 27001.
Risk assessment drives control selection.
Annex A provides a reference set of information security controls, but organizations should determine which controls are relevant based on their risks and other requirements.
For example:
Risk
Employees may fall victim to phishing attacks.
Possible treatment
Improve employee security awareness and phishing resilience.
Relevant controls may include
- Information security awareness, education and training
- Identity and access management
- Authentication information
- Monitoring activities
- Other technical or organizational measures
The organization should document why controls are selected and how they address identified risks.
12. Risk → Control → Evidence
A useful way to implement ISO 27001 is to maintain a clear connection between:
Risk
↓
Risk Treatment
↓
Control
↓
Implementation
↓
Evidence
For example:
| Risk | Treatment | Control | Evidence |
|---|---|---|---|
| Unauthorized access | Strengthen authentication | Authentication controls | MFA configuration |
| Data leakage | Restrict access | Access control | Access review records |
| Malware infection | Endpoint protection | Malware protection | EDR dashboard |
| Data loss | Improve backups | Backup controls | Backup reports |
| Supplier security weakness | Assess suppliers | Supplier security requirements | Vendor assessment |
This traceability makes the ISMS easier to manage and easier to audit.
13. Risk Treatment Plan
A Risk Treatment Plan (RTP) translates identified risks into actions.
A typical RTP may contain:
| Field | Example |
|---|---|
| Risk ID | R-001 |
| Risk | Unauthorized access to production |
| Risk owner | CTO |
| Initial risk | High |
| Treatment | Reduce |
| Action | Implement MFA |
| Responsible person | Infrastructure Lead |
| Target date | 30-Nov-2026 |
| Relevant control | Access control |
| Residual risk | Medium |
| Approval | Management |
The plan should be actively managed rather than created only for certification.
14. What Is Residual Risk?
After controls are implemented, some risk may remain.
This is called residual risk.
For example:
Initial risk: High
↓
MFA + privileged access management + monitoring
↓
Residual risk: Medium
The organization should determine whether the remaining risk is acceptable.
If it is not acceptable, additional treatment may be necessary.
15. Risk Owners
Every significant risk should have an appropriate risk owner.
The risk owner is responsible for understanding and managing the risk and ensuring that appropriate treatment decisions are made.
For example:
- CTO → Technology risks
- CISO → Security risks
- CFO → Financial risks
- HR Head → People-related risks
- Procurement → Supplier risks
The risk owner does not necessarily have to personally implement every control.
16. How Often Should Risk Assessments Be Performed?
There is no universal requirement that every organization must perform a complete risk assessment every specific number of months.
The organization should define its review criteria.
A reassessment may be triggered by:
- Major technology changes
- New products or services
- New customers
- Significant organizational changes
- New regulations
- New suppliers
- Major cybersecurity incidents
- Significant vulnerabilities
- Cloud migration
- Mergers or acquisitions
- Changes in business processes
Many organizations also perform periodic reviews according to their defined ISMS processes.
17. Risk Assessment for Startups
Startups should avoid making risk assessment unnecessarily complicated.
A practical startup approach is:
Step 1
Identify critical information and systems.
Step 2
Identify realistic threats and vulnerabilities.
Step 3
Assess likelihood and impact.
Step 4
Prioritize significant risks.
Step 5
Define treatment actions.
Step 6
Map treatments to relevant ISO 27001 controls.
Step 7
Implement controls.
Step 8
Collect evidence.
Step 9
Evaluate residual risk.
Step 10
Review risks when the business or technology changes.
A simple, well-maintained risk register is usually more useful than a complex spreadsheet that nobody updates.
18. Common Risk Assessment Mistakes
Mistake 1 – Copying another company’s risk register
Every organization has a different context, architecture, customers, and risk profile.
Mistake 2 – Selecting controls first
The process should generally begin with understanding the organization’s risks and requirements rather than blindly selecting every Annex A control.
Mistake 3 – Treating risk scoring as the objective
A numerical score is a decision-support mechanism. It should not replace management judgment and documented criteria.
Mistake 4 – Ignoring business impact
Cybersecurity risk is not only about technical vulnerabilities.
Consider financial, operational, contractual, legal, customer, and business consequences.
Mistake 5 – Creating the risk register only for the auditor
The risk register should support actual business decisions throughout the year.
Mistake 6 – Never reviewing residual risk
A risk should not automatically be considered closed simply because a control has been implemented.
Mistake 7 – Treating Annex A as a checklist
Annex A should be considered within the organization’s risk treatment and control-selection process.
19. Typical ISO 27001 Risk Assessment Documents
An organization may maintain documents and records such as:
- Risk Assessment Methodology
- Risk Criteria
- Risk Register
- Risk Treatment Plan
- Statement of Applicability (SoA)
- Control implementation records
- Risk acceptance records
- Risk review records
- Management approval records
- Internal audit evidence
- Corrective action records
The exact documentation should reflect the organization’s ISMS and documented information requirements.
20. Risk Assessment and Statement of Applicability
The Statement of Applicability (SoA) is closely connected to risk treatment.
The SoA records the organization’s decisions regarding the applicable Annex A controls, including:
- Which controls are applicable
- Whether controls are implemented
- Justification for inclusion
- Justification for exclusion where applicable
- Implementation status
The risk assessment helps provide the rationale behind these decisions.
Therefore:
Risk Assessment → Risk Treatment → Control Selection → Statement of Applicability → Implementation → Evidence
21. Practical Example
Consider a SaaS startup storing customer information in a cloud environment.
Identified asset
Customer database
Threat
Compromised administrator credentials
Vulnerability
MFA is not enabled for privileged accounts.
Potential impact
- Unauthorized access
- Customer data exposure
- Service disruption
- Contractual consequences
- Reputational impact
Risk assessment
Likelihood = 4
Impact = 5
Initial Risk = 20
Treatment
Reduce the risk by:
- Implementing MFA
- Applying least privilege
- Reviewing privileged accounts
- Monitoring privileged activity
- Improving authentication controls
Residual risk
After implementation, management reassesses the risk.
If the residual risk is within the organization’s acceptance criteria, management may approve it.
This creates a clear connection between the organization’s business risk and its security controls.
22. ISO 27001 Risk Assessment Checklist
Before considering the risk assessment process mature, ask:
- Is a documented risk assessment methodology available?
- Are risk criteria defined?
- Are important information assets identified?
- Are relevant threats and vulnerabilities considered?
- Are likelihood and impact evaluated consistently?
- Are risk owners assigned?
- Are risk acceptance criteria defined?
- Are treatment decisions documented?
- Are treatment actions tracked?
- Are relevant controls linked to risks?
- Is the Statement of Applicability aligned with the risk treatment process?
- Are residual risks evaluated?
- Are risks formally accepted where appropriate?
- Are significant changes triggering reassessment?
- Is the risk register periodically reviewed?
- Can the organization demonstrate evidence of the process to an auditor?
23. The Key Principle
ISO 27001 risk assessment is not about creating the largest possible risk register or implementing the maximum number of security controls.
It is about making informed, repeatable, and documented decisions about information security risk.
The objective is to understand:
What could happen, how much it could affect the organization, what the organization will do about it, and whether the remaining risk is acceptable.
When risk assessment is properly connected to control selection, implementation, monitoring, and management decisions, ISO 27001 becomes a practical information security management system rather than simply a certification exercise.
Quick Summary for Startups
Identify → Analyze → Evaluate → Treat → Implement → Verify → Review
A startup preparing for ISO 27001 should focus first on its critical information, systems, people, suppliers, and business processes.
Then identify realistic risks, prioritize them, define appropriate treatments, select relevant controls, implement those controls, maintain evidence, and continuously review the remaining risk.
Risk should drive security — not the other way around.
Example of ABC Startup – https://iso27001.makeauditeasy.in/docs/iso-27001/other-doc/s/