A Practical, Risk-Based Approach for Startups

Risk assessment is one of the most important parts of an ISO/IEC 27001 Information Security Management System (ISMS).

The purpose is not to create a complicated risk register.

The purpose is to answer four practical questions:

What information and systems are important to our business?
What could go wrong?
How serious would it be?
What should we do about it?

ISO/IEC 27001 requires organizations to establish and apply an information security risk assessment process and use the results to determine appropriate risk treatment. The standard does not prescribe one universal scoring formula; organizations define a methodology appropriate to their context and risk criteria.

1. What Is an ISO 27001 Risk Assessment?

An ISO 27001 risk assessment is a structured process for identifying and evaluating information security risks that could affect the confidentiality, integrity or availability of information.

A simplified model is:

Asset / Information
↓
Threat / Risk Event
↓
Vulnerability / Weakness
↓
Impact
↓
Likelihood
↓
Risk Level
↓
Risk Treatment

Example

A SaaS startup stores customer information in an AWS database.

Information: Customer data

Threat/Event: Unauthorized access

Weakness: Excessive administrator permissions

Impact: Customer information could be disclosed

Likelihood: Possible/high

Risk: Unauthorized access to customer data

Treatment: Reduce

Controls: MFA, least privilege, access reviews, logging and monitoring

2. Why Risk Assessment Matters

Risk assessment prevents an organization from treating every security issue as equally important.

Consider these two issues:

Risk A

An employee’s screen-lock timeout is configured for 10 minutes instead of 5 minutes.

Risk B

An administrator account has unrestricted access to the production customer database without MFA.

Both are security issues.

But their potential business consequences are very different.

Risk assessment allows the organization to prioritize resources according to risk.

3. ISO 27001 Risk Assessment Principles

A practical risk assessment should be:

Business-focused

Understand what could affect the organization’s objectives.

Repeatable

Use a consistent methodology.

Evidence-based

Use information about actual systems, assets, threats and vulnerabilities.

Risk-based

Prioritize significant risks rather than treating everything equally.

Dynamic

Update the assessment when important changes occur.

Action-oriented

Risk assessment should lead to treatment decisions.

4. Step 1 — Define the Risk Assessment Methodology

Before assessing individual risks, define how the organization will assess them.

The methodology should explain:

What constitutes a risk
How risks are identified
How likelihood is assessed
How impact is assessed
How risk is calculated or categorized
How risks are prioritized
Risk acceptance criteria
Who owns risks
When risks are reassessed

The methodology should be appropriate to the organization’s size, complexity and risk environment.

5. Example 5 × 5 Risk Scoring Method

A startup may choose a simple 1–5 scale.

Likelihood

Score	Likelihood	Description
1	Rare	Highly unlikely
2	Unlikely	Could occur but not expected
3	Possible	Could reasonably occur
4	Likely	Expected to occur periodically
5	Almost Certain	Expected frequently or imminent

Impact

Score	Impact	Description
1	Insignificant	Minimal business/security impact
2	Minor	Limited impact
3	Moderate	Noticeable operational/business impact
4	Major	Significant business/security impact
5	Severe	Critical business, legal, regulatory or customer impact

Risk Score

A simple methodology can calculate:

Risk Score = Likelihood × Impact

For example:

Likelihood = 4

Impact = 5

Risk = 4 × 5 = 20

The organization then defines its own risk categories.

For example:

Score	Category
1–4	Low
5–9	Medium
10–15	High
16–25	Critical

These numbers are an example methodology—not an ISO 27001-mandated scoring system.

6. Step 2 — Identify the ISMS Scope

Risk assessment should relate to the organization’s defined ISMS scope.

For example:

Development, operation and support of a SaaS platform and its supporting corporate environment hosted on AWS.

This scope determines what should be considered during the risk assessment.

Consider:

Applications
Infrastructure
Information
People
Processes
Locations
Suppliers
Technology
Supporting services

7. Step 3 — Identify Important Assets and Information

Start with important information and business assets.

For an AWS SaaS startup:

Asset	Example
SaaS application	Customer-facing platform
Customer database	AWS RDS
Customer files	Amazon S3
Source code	GitHub
AWS environment	Production infrastructure
Employee laptops	Corporate endpoints
Credentials	IAM/application credentials
Security logs	CloudTrail/SIEM
Backups	AWS Backup
Employee information	HR systems

You don’t need to list every mouse, keyboard or low-value item.

Focus on assets whose compromise could affect the organization’s security, operations, customers or obligations.

8. Step 4 — Identify Threats and Risk Events

Ask:

What could happen to this asset?

Typical information security risk events include:

Unauthorized access
Data leakage
Malware/ransomware
Phishing
Credential theft
Accidental deletion
Hardware failure
Cloud outage
Software vulnerability exploitation
Insider misuse
Supplier compromise
Inadequate backup
Misconfiguration
Lost/stolen device
Denial-of-service attack

9. Step 5 — Identify Vulnerabilities and Weaknesses

A threat becomes more meaningful when you understand why the risk could occur.

Example

Risk Event: Unauthorized AWS access

Possible weaknesses:

No MFA
Excessive privileges
Shared administrator accounts
Poor access reviews
Long-lived credentials
Weak password controls
Inadequate logging
No privileged access monitoring

The assessment should consider existing controls as well.

10. Step 6 — Assess Potential Impact

Impact should consider more than financial loss.

Depending on the organization, consider:

Confidentiality

Could information be disclosed?

Integrity

Could information be modified incorrectly?

Availability

Could systems or information become unavailable?

Business Operations

Could the company stop providing services?

Customers

Could customers be affected?

Legal/Regulatory

Could the organization violate applicable requirements?

Contractual

Could customer or partner obligations be breached?

Reputation

Could trust in the organization be affected?

11. Step 7 — Assess Likelihood

Consider factors such as:

Existing vulnerabilities
Threat exposure
Internet exposure
Existing controls
Attack frequency
Historical incidents
Employee behavior
Supplier dependency
Technical complexity
Ease of exploitation

Example

A production database directly exposed to the internet with weak authentication would generally warrant a different likelihood assessment from a database isolated behind multiple security controls.

The assessment should be based on the organization’s defined criteria rather than arbitrary scoring.

12. Step 8 — Calculate or Categorize the Risk

Using the example methodology:

Likelihood × Impact

Example:

Likelihood: 4
Impact: 5

Initial Risk: 20 — Critical

The risk register should record the rationale behind the rating where useful.

13. Example Risk Register — AWS SaaS Startup

Consider a fictional company:

ABC SaaS Pvt. Ltd.

Technology:

AWS
EC2/ECS
RDS
S3
IAM
CloudFront
WAF
CloudTrail
CloudWatch
GitHub
Employee laptops

Sample Risk Register

ID	Risk	Asset	L	I	Score	Level	Treatment
R-001	Unauthorized production access	AWS	4	5	20	Critical	Reduce
R-002	Customer data exposure	S3/RDS	4	4	16	Critical	Reduce
R-003	Application vulnerability exploited	SaaS App	4	5	20	Critical	Reduce
R-004	Ransomware on endpoints	Laptops	3	4	12	High	Reduce
R-005	Database failure/data loss	RDS	3	5	15	High	Reduce
R-006	Cloud service outage	AWS	3	4	12	High	Reduce/Accept
R-007	Supplier security incident	SaaS suppliers	3	4	12	High	Reduce/Share
R-008	Employee phishing	Corporate systems	4	4	16	Critical	Reduce

14. Step 9 — Identify Existing Controls

Do not assume that a risk exists without considering controls already operating.

For example:

Risk

Unauthorized AWS production access.

Existing controls

MFA
IAM roles
Least privilege
Access reviews
CloudTrail
Monitoring

The controls may reduce likelihood or impact.

Therefore, distinguish between:

Inherent/Initial Risk

and

Residual Risk

15. Initial Risk vs Residual Risk

This is an important concept.

Initial Risk

Risk before considering the planned or existing treatment, depending on the organization’s defined methodology.

Residual Risk

Risk remaining after controls/treatment are considered.

Example

Risk: Unauthorized AWS production access

Initial Risk: 20 — Critical

Treatment:

MFA
Least privilege
Privileged access
Quarterly access review
CloudTrail
Monitoring

After implementation:

Residual Likelihood: 2

Residual Impact: 5

Residual Risk: 10 — High

The risk is still present.

Controls generally reduce risk; they do not necessarily eliminate it.

The organization then decides whether the residual risk is acceptable.

16. Step 10 — Select Risk Treatment

For each significant risk, determine an appropriate treatment.

Common options are:

Reduce

Implement controls to reduce likelihood and/or impact.

Example: MFA to reduce unauthorized account access.

Avoid

Stop the activity that creates the risk.

Example: Discontinue an unnecessary insecure service.

Share/Transfer

Transfer or share some risk through appropriate contractual, insurance or service arrangements.

Example: Using a specialized cloud provider for certain infrastructure responsibilities.

Accept

Retain the risk when it falls within the organization’s defined acceptance criteria and the appropriate authority accepts it.

17. Step 11 — Map Risks to Controls

This creates traceability between risk assessment and control implementation.

Example

R-001: Unauthorized AWS Production Access

Possible controls:

Access control
Identity management
Authentication
Access rights management
Privileged access management
Logging
Monitoring

The organization can then map these to relevant ISO 27001 Annex A controls and any additional necessary controls.

18. Risk → Control → Evidence

A mature ISMS should establish this chain:

Risk

Unauthorized AWS production access

↓

Control

Privileged access management

↓

Implementation

AWS IAM + MFA + least privilege

↓

Evidence

IAM configuration
MFA status
Access approval
Access review
CloudTrail logs

↓

Internal Audit

Sample privileged users and verify actual access.

This traceability is one of the most valuable features of a risk-based ISMS.

19. Step 12 — Assign Risk Owners

Every significant risk should have an owner.

Example

Risk	Risk Owner
AWS production access	CTO
Application vulnerability	Engineering Lead
Employee security	HR Manager
Supplier risk	Operations/Procurement
Customer data protection	Security/Compliance Lead
Business continuity	CEO/COO

The risk owner is accountable for ensuring that the risk is appropriately managed.

20. Step 13 — Create the Risk Treatment Plan

The Risk Treatment Plan converts risk decisions into actions.

Risk	Treatment	Action	Owner	Target	Status
R-001	Reduce	Enforce MFA	CTO	15 Oct	Complete
R-002	Reduce	Restrict S3 access	Cloud Lead	20 Oct	In Progress
R-003	Reduce	External VAPT	Engineering	30 Oct	Planned
R-004	Reduce	Endpoint protection	IT	15 Oct	Complete

The treatment plan should be actively managed rather than created once for certification.

21. Step 14 — Connect the Risk Register to the SoA

The Risk Register answers:

What can go wrong?

The Risk Treatment Plan answers:

What are we going to do about it?

The Statement of Applicability answers:

Which necessary controls have we selected, why are they applicable, and what is their implementation status?

The Evidence answers:

Can we demonstrate that the controls are actually operating?

Therefore:

Risk Register → Treatment Plan → Necessary Controls → SoA → Implementation → Evidence

ISO/IEC 27001’s Auditing Practices Group notes that necessary controls are determined through the organization’s risk treatment process and then compared with Annex A; necessary controls can also arise from other sources.

22. When Should a Startup Perform Risk Assessment?

Risk assessment should not be a one-time certification exercise.

It should be reviewed at planned intervals and when significant changes occur.

Examples of triggers include:

New application
New cloud environment
Major architecture change
New customer requirements
New regulatory requirements
New supplier
Major security incident
Significant vulnerability
Acquisition/merger
New geographic market
Major business process change

Example

A startup moves from:

AWS single-region architecture

to:

AWS multi-region architecture

That may introduce new:

Assets
Suppliers/services
Data flows
Access requirements
Availability risks
Operational risks

The risk assessment should therefore be reviewed.

23. Risk Assessment Evidence

An auditor may expect to see evidence such as:

Risk assessment methodology
Risk register
Risk scoring criteria
Risk treatment plan
Risk acceptance records
Risk review records
Asset inventory
Threat/vulnerability information
Control mapping
SoA
Residual risk assessment

The organization should retain evidence appropriate to its ISMS and applicable requirements.

24. Common Startup Risk Assessment Mistakes

❌ Copying a generic risk register

A copied risk register may not reflect the company’s actual environment.

Better: Build risks from the organization’s actual assets, processes, technology and business model.

❌ Listing threats without risks

“Phishing” by itself is not a useful risk statement.

Better:

Phishing may result in compromise of employee credentials and unauthorized access to corporate systems.

❌ Treating every risk as Critical

If everything is Critical, nothing is prioritized.

Use defined criteria consistently.

❌ Ignoring existing controls

Risk assessment should consider the controls already implemented according to the organization’s methodology.

❌ Accepting risks without authority

Risk acceptance should follow the organization’s defined approval criteria and authority.

❌ Never updating the risk register

A six-month-old risk assessment may not reflect the current technology or business environment.

❌ Selecting controls before understanding risks

Do not begin with:

“Which Annex A controls should we implement?”

Begin with:

“What information security risks does our organization need to manage?”

25. Startup Risk Assessment Template

A practical risk register can use the following fields:

Field	Description
Risk ID	Unique identifier
Asset / Process	What is being protected
Risk Description	What could happen
Threat / Event	Potential event
Vulnerability / Cause	Why it could happen
CIA Impact	Confidentiality / Integrity / Availability
Existing Controls	Current safeguards
Likelihood	Defined organizational scale
Impact	Defined organizational scale
Initial Risk	Pre-treatment risk
Risk Level	Low/Medium/High/Critical or equivalent
Treatment	Reduce/Avoid/Share/Accept
Treatment Action	What will be done
Risk Owner	Accountable owner
Control(s)	Relevant controls
Target Date	Treatment deadline
Residual Likelihood	Post-treatment rating
Residual Impact	Post-treatment rating
Residual Risk	Remaining risk
Acceptance Decision	Accepted / Further Treatment
Evidence	Supporting records
Review Date	Next review

26. A Simple Startup Risk Assessment Workflow

Step 1

Define ISMS scope.

↓

Step 2

Identify important information, assets and processes.

↓

Step 3

Identify threats, vulnerabilities and risk events.

↓

Step 4

Assess likelihood and impact.

↓

Step 5

Determine initial risk.

↓

Step 6

Identify existing controls.

↓

Step 7

Determine risk treatment.

↓

Step 8

Select necessary controls.

↓

Step 9

Implement treatment.

↓

Step 10

Assess residual risk.

↓

Step 11

Accept or further treat residual risk.

↓

Step 12

Map necessary controls to the SoA.

↓

Step 13

Monitor and periodically reassess.

27. Practical Example — Complete Risk Assessment

Risk R-001

Asset: AWS Production Environment

Risk: Unauthorized access to production resources could result in data exposure or service disruption.

Threat: Compromised administrator credentials.

Vulnerabilities:

Excessive privileges
Inadequate access review
Credential compromise

Initial Assessment

Likelihood: 4

Impact: 5

Initial Risk: 20 — Critical

Treatment

Reduce

Controls

MFA
Least privilege
Role-based access
Privileged access management
Access reviews
Logging
Monitoring

Implementation

AWS IAM
MFA
Separate administrative roles
Quarterly access review
CloudTrail
CloudWatch

Evidence

IAM configuration
MFA report
Access approvals
Access review records
CloudTrail logs
Monitoring alerts

Residual Assessment

Likelihood: 2

Impact: 5

Residual Risk: 10 — High

Decision

The organization evaluates whether the residual risk falls within its defined acceptance criteria. If it does not, additional treatment is required.

28. Risk Assessment Is Not the Same as Vulnerability Assessment

These terms are often confused.

Vulnerability Assessment

Primarily identifies technical weaknesses.

Examples:

Missing security patch
Vulnerable software
Open port
Weak configuration

Risk Assessment

Considers the broader business/security risk.

Example:

A vulnerable internet-facing application could allow unauthorized access to customer information, resulting in service disruption, contractual consequences and customer impact.

A vulnerability can therefore become an input into the broader risk assessment.

29. Risk Assessment vs Risk Treatment

Risk Assessment

What is the risk?

Risk Treatment

What are we going to do about it?

Risk Acceptance

Are we willing to retain the remaining risk?

Risk Monitoring

Has the risk changed?

These should be treated as connected but distinct activities.

30. Final Principle

A good ISO 27001 risk assessment is not a spreadsheet exercise.

It is a decision-making process.

The objective is to help management answer:

What information security risks could affect our business, how significant are they, what are we doing about them, and is the remaining risk acceptable?

For a startup, the strongest approach is usually:

Business Context
↓
ISMS Scope
↓
Assets & Processes
↓
Risks
↓
Risk Treatment
↓
Necessary Controls
↓
Statement of Applicability
↓
Implementation
↓
Evidence
↓
Residual Risk
↓
Internal Audit & Management Review
↓
Continual Improvement

The goal is not to eliminate every possible risk.

The goal of an effective ISMS is to understand information security risks, treat them appropriately, and maintain the organization’s risk within its defined acceptance criteria.