Assume “ABC SaaS Pvt. Ltd.” operates a B2B SaaS application hosted on AWS.
Architecture:
- AWS EC2 / ECS for application
- Amazon RDS for customer database
- Amazon S3 for documents
- IAM for access management
- CloudFront + WAF
- CloudWatch / CloudTrail for logging
- AWS Backup
- GitHub for source code
- Employees access AWS remotely
- Customers access the SaaS application over HTTPS
The company wants to implement ISO 27001.
1. Identify the Critical Assets
First, don’t start with Annex A controls. Start with what the startup needs to protect.
| Asset | Where | Importance |
|---|---|---|
| Customer data | Amazon RDS | Critical |
| Customer documents | Amazon S3 | Critical |
| SaaS application | AWS ECS/EC2 | Critical |
| Source code | GitHub | High |
| AWS production account | AWS IAM | Critical |
| Employee accounts | Google Workspace/IdP | High |
| Logs | CloudWatch / CloudTrail | High |
| Backups | AWS Backup/S3 | Critical |
| API keys/secrets | AWS Secrets Manager | Critical |
| Laptop endpoints | Employee devices | Medium/High |
| Customer contracts | Document repository | High |
2. Identify a Realistic Risk
Let’s take one of the most important risks.
Risk R-001
Unauthorized access to the AWS production environment
The startup has several engineers who need AWS access.
One engineer’s credentials could be compromised through:
- phishing
- credential theft
- malware
- leaked access keys
- compromised workstation
An attacker could potentially obtain access to production resources.
3. Identify the Vulnerability
Suppose during the assessment we discover:
One developer has direct AWS administrative privileges and MFA is not enforced for all privileged access.
Now we have:
Threat: Compromised employee credentials
Vulnerability: Excessive privilege + inadequate authentication protection
Asset: AWS production environment
4. Determine the Impact
If the account is compromised, an attacker could potentially:
- Access customer information
- Modify infrastructure
- Delete resources
- Access S3 buckets
- Access databases
- Deploy malicious code
- Disable security monitoring
- Create unauthorized AWS resources
- Cause service disruption
Potential business consequences include:
- Customer data exposure
- Service outage
- Financial loss
- Contractual consequences
- Regulatory consequences
- Customer trust impact
Therefore, the impact is high.
5. Determine Likelihood
Now ask:
How likely is this to happen?
Suppose:
- Employees use cloud services daily
- Phishing is a realistic threat
- Privileged accounts exist
- MFA is not consistently enforced
- Some access is broader than necessary
We could assign:
Likelihood = 4 / 5
And:
Impact = 5 / 5
Therefore:
Risk = Likelihood × Impact
4 × 5 = 20
If the organization’s methodology defines 16–25 as Critical:
Initial Risk = Critical
6. Create the Risk Register Entry
The risk register could look like this:
| Field | Assessment |
|---|---|
| Risk ID | R-001 |
| Asset | AWS Production Environment |
| Risk | Unauthorized access to AWS production |
| Threat | Credential compromise |
| Vulnerability | Excessive privileges / inconsistent MFA |
| Likelihood | 4 |
| Impact | 5 |
| Initial Risk | 20 – Critical |
| Risk Owner | CTO |
| Treatment | Reduce |
| Treatment Actions | MFA, least privilege, access review, monitoring |
| Residual Risk | To be assessed |
| Status | Open |
This is a much better ISO 27001 approach than simply writing:
“AWS security – High”
because the auditor and management can understand why the risk exists.
7. Decide the Risk Treatment
Management decides:
We don’t want to accept this level of risk.
Therefore:
Risk Treatment = Reduce
The startup decides to implement:
Authentication
- Enforce MFA
- Use centralized identity where appropriate
- Disable unnecessary access keys
- Strengthen authentication policies
Authorization
- Remove unnecessary administrator privileges
- Implement least privilege
- Separate development and production access
- Use role-based access
Monitoring
- Enable CloudTrail
- Monitor privileged activity
- Alert on suspicious authentication events
Access Review
- Review AWS users and roles periodically
- Remove terminated employees immediately
- Review privileged access periodically
8. Map the Treatment to Controls
Now we connect the risk treatment to ISO 27001 controls.
For example, relevant controls may include controls addressing:
- Identity management
- Authentication information
- Access rights
- Privileged access
- Access restrictions
- Logging
- Monitoring
- Configuration management
- Information security in use of cloud services
The important point is:
The risk led us to the controls.
We didn’t start by saying:
“Let’s implement every Annex A control.”
9. Implement the AWS Controls
Now the startup actually implements the treatment.
AWS IAM
Instead of:
Developer → AdministratorAccess
we move toward:
Developer → Developer Role
DevOps → Production Deployment Role
Security → Security Monitoring Role
CTO → Controlled Administrative Role
Access is granted according to business requirements.
10. Enable MFA
For privileged access:
Password
MFA
becomes required.
This reduces the likelihood that a stolen password alone can be used to access the AWS environment.
11. Enable CloudTrail
The company enables AWS CloudTrail to record important API activity.
For example:
Who created an IAM user?
Who changed a security group?
Who accessed a sensitive resource?
Who modified production infrastructure?
This creates audit evidence as well as security visibility.
12. Implement Access Reviews
Suppose the company has:
12 AWS users
During the quarterly access review:
| User | Role | Required? | Action |
|---|---|---|---|
| CTO | Admin | Yes | Retain |
| DevOps | Production | Yes | Retain |
| Developer 1 | Admin | No | Remove |
| Developer 2 | Developer | Yes | Retain |
| Former employee | Developer | No | Disable |
This is important because the control must operate in practice.
Having an IAM policy document alone doesn’t demonstrate effective access management.
13. Recalculate the Risk
After implementing the controls, reassess the risk.
Before treatment:
Likelihood = 4
Impact = 5
Risk = 20
After:
- MFA implemented
- Least privilege implemented
- Privileged access restricted
- CloudTrail enabled
- Access reviews implemented
- Monitoring implemented
Management may determine:
Likelihood = 2
Impact = 5
Therefore:
Residual Risk = 2 × 5 = 10
The impact hasn’t necessarily changed.
What changed is the likelihood.
14. Is the Residual Risk Acceptable?
Suppose the organization’s risk acceptance criteria says:
| Score | Category |
|---|---|
| 1–4 | Low |
| 5–9 | Medium |
| 10–15 | High |
| 16–25 | Critical |
Residual risk:
10 = High
Management now has to decide whether this residual risk is acceptable according to the organization’s defined criteria.
If acceptable:
Risk is formally accepted.
If not:
Additional treatment is required.
This is a key part of ISO 27001.
15. Complete Risk Assessment
The final register might look like:
| Risk | Initial | Treatment | Controls / Actions | Residual | Decision |
|---|---|---|---|---|---|
| AWS unauthorized access | 20 Critical | Reduce | MFA, least privilege, IAM review, CloudTrail, monitoring | 10 High | Management review |
| S3 data exposure | 16 Critical | Reduce | Block public access, encryption, access review, logging | 6 Medium | Accept |
| RDS data loss | 15 High | Reduce | Backup, recovery testing, monitoring | 5 Medium | Accept |
| Application vulnerability | 16 Critical | Reduce | VAPT, secure SDLC, patching | 8 Medium | Accept |
| Ransomware | 12 High | Reduce | EDR, backup, awareness, segmentation | 6 Medium | Accept |
| AWS outage | 10 High | Reduce/Accept | Backup, DR, availability architecture | 8 Medium | Accept |
| Supplier compromise | 12 High | Reduce | Supplier assessment, contractual controls | 6 Medium | Accept |
16. Now the Important ISO 27001 Connection
This is where the startup’s ISO 27001 system becomes logical:
AWS SaaS Environment
↓
Identify Assets
↓
Identify Threats & Vulnerabilities
↓
Assess Likelihood & Impact
↓
Calculate Initial Risk
↓
Risk Treatment Decision
↓
Select Relevant Controls
↓
Implement Controls
↓
Collect Evidence
↓
Assess Residual Risk
↓
Management Acceptance
↓
Continuous MonitoringAnd this ultimately feeds into the:
Statement of Applicability (SoA)
17. Example: S3 Risk
Let’s take another AWS-specific example.
Asset
Customer documents stored in S3.
Threat
Unauthorized public exposure.
Vulnerability
An S3 bucket could accidentally be configured for public access.
Impact
Customer information could become publicly accessible.
Likelihood
3
Impact
5
Initial Risk
3 × 5 = 15 – High
Treatment
- S3 Block Public Access
- Bucket policies
- IAM least privilege
- Encryption
- Logging
- Periodic access review
- Configuration monitoring
Residual Risk
Suppose:
Likelihood = 1
Impact = 5
Residual Risk = 5 – Medium
Management reviews and accepts the residual risk if it meets the organization’s defined criteria.
18. Example: RDS Backup Risk
Asset
Customer database.
Threat
Database failure or accidental deletion.
Vulnerability
Backup configuration is inadequate or restoration has never been tested.
Impact
Potential customer service disruption and data loss.
Initial assessment
Likelihood = 3
Impact = 5
Risk = 15 – High
Treatment
- Automated backups
- Backup retention
- Database snapshots
- Backup monitoring
- Restore testing
- Documented recovery procedures
After treatment:
Likelihood = 1
Impact = 5
Residual Risk = 5 – Medium
19. Example: GitHub Source Code
Asset
Source code.
Threat
Compromise of developer GitHub account.
Vulnerability
No MFA and excessive repository permissions.
Impact
- Source-code theft
- Malicious code changes
- Intellectual property loss
- Supply-chain risk
Initial:
Likelihood 4 × Impact 4 = 16
Treatment:
- MFA
- Branch protection
- Repository access control
- Code review
- Secret scanning
- Security monitoring
- Access reviews
Residual:
Likelihood 2 × Impact 4 = 8
20. What the Auditor Will Want to See
For this AWS SaaS startup, an auditor should be able to follow the evidence chain:
Risk
Unauthorized AWS access
↓
Risk treatment
Reduce
↓
Control
Access management / authentication / logging
↓
Implementation
MFA + IAM least privilege + CloudTrail
↓
Evidence
IAM configuration
MFA records
Access review
CloudTrail configuration
Monitoring alerts
↓
Residual risk
10
↓
Management decision
Accepted / further treatment
That traceability is what makes the risk assessment useful.
The key lesson for a startup
An AWS SaaS company does not need to say:
“We use AWS, therefore we need 114 ISO controls.”
Instead, it should say:
“These are our assets, these are our risks, these are the treatments we selected, and these are the controls we implemented to reduce those risks.”
That is the practical thinking behind an ISO 27001 risk-based ISMS.