AWS-Based SaaS Startup — Sample
Organization: ABC SaaS Pvt. Ltd.
ISMS: Information Security Management System
Standard: ISO/IEC 27001:2022
Scope: Development, operation and support of the SaaS platform and supporting corporate environment hosted on AWS.
Risk scale
| Score | Level |
|---|---|
| 1–4 | Low |
| 5–9 | Medium |
| 10–15 | High |
| 16–25 | Critical |
1. Master SoA
| Control | Applicable | Why Applicable | Risk ID | Treatment | Status | Evidence |
|---|---|---|---|---|---|---|
| A.5.1 Policies for information security | Yes | ISMS requires documented security direction and requirements | R-01 | Reduce | Implemented | Security policies |
| A.5.2 Information security roles and responsibilities | Yes | Security responsibilities need clear ownership | R-01 | Reduce | Implemented | RACI / job roles |
| A.5.3 Segregation of duties | Yes | Development, approval and production administration need separation | R-02 | Reduce | Partial | Access matrix |
| A.5.7 Threat intelligence | Yes | SaaS/AWS environment faces changing cyber threats | R-03 | Reduce | Implemented | Threat intelligence records |
| A.5.8 Information security in project management | Yes | Security must be considered when developing new features | R-04 | Reduce | Implemented | Project checklist |
| A.5.9 Inventory of information and associated assets | Yes | AWS resources, applications and information must be identified | R-05 | Reduce | Implemented | Asset register |
| A.5.12 Classification of information | Yes | Customer and company information have different sensitivity levels | R-06 | Reduce | Implemented | Data classification |
| A.5.14 Information transfer | Yes | Customer information moves through APIs, email and cloud services | R-06 | Reduce | Implemented | Transfer procedure |
| A.5.15 Access control | Yes | Access to AWS, SaaS and corporate systems must be restricted | R-01 | Reduce | Implemented | Access policy |
| A.5.16 Identity management | Yes | User identities must be controlled throughout their lifecycle | R-01 | Reduce | Implemented | IAM/IdP |
| A.5.17 Authentication information | Yes | Passwords, tokens, API keys and credentials require protection | R-01 | Reduce | Implemented | IAM/MFA |
| A.5.18 Access rights | Yes | Access must be approved, reviewed and removed | R-01 | Reduce | Implemented | Access review |
| A.5.19 Supplier relationships | Yes | AWS and other suppliers support critical services | R-07 | Reduce | Implemented | Supplier register |
| A.5.20 Supplier agreements | Yes | Security requirements must be addressed contractually | R-07 | Reduce | Implemented | Contracts |
| A.5.21 ICT supply chain | Yes | SaaS depends on AWS, GitHub and other technology suppliers | R-07 | Reduce | Implemented | Supplier assessments |
| A.5.23 Cloud services | Yes | AWS is the primary hosting environment | R-01/R-08 | Reduce | Implemented | AWS assessment |
| A.5.24 Incident management planning | Yes | Security incidents require defined response procedures | R-09 | Reduce | Implemented | IR plan |
| A.5.25 Event assessment | Yes | Events must be assessed to determine whether they are incidents | R-09 | Reduce | Implemented | Incident records |
| A.5.26 Incident response | Yes | SaaS/AWS incidents can affect customers and operations | R-09 | Reduce | Implemented | IR procedure |
| A.5.27 Lessons from incidents | Yes | Incidents should improve the ISMS | R-09 | Reduce | Implemented | PIR records |
| A.5.28 Collection of evidence | Yes | Logs/evidence may be required for investigations | R-09 | Reduce | Implemented | Evidence procedure |
| A.5.29 Security during disruption | Yes | Security must continue during business disruption | R-10 | Reduce | Implemented | BCP |
| A.5.30 ICT readiness for business continuity | Yes | SaaS availability depends on AWS infrastructure | R-10 | Reduce | Implemented | DR plan/test |
| A.5.31 Legal/regulatory/contractual requirements | Yes | Customer, legal and regulatory requirements apply | R-11 | Reduce | Implemented | Compliance register |
| A.5.33 Protection of records | Yes | Security, audit and business records require protection | R-12 | Reduce | Implemented | Records procedure |
| A.5.34 Privacy and protection of PII | Yes | SaaS processes customer/employee personal information | R-13 | Reduce | Implemented | Privacy controls |
| A.5.35 Independent review | Yes | ISMS effectiveness requires independent review | R-14 | Reduce | Planned | Internal audit |
| A.5.37 Documented operating procedures | Yes | AWS and security operations require repeatable procedures | R-01/R-10 | Reduce | Implemented | SOPs |
2. People Controls
| Control | Applicable | Why Applicable | Risk | Status |
|---|---|---|---|---|
| A.6.1 Screening | Yes | Employees receive access to sensitive information/systems | R-15 | Implemented |
| A.6.2 Terms and conditions | Yes | Security responsibilities must form part of employment | R-15 | Implemented |
| A.6.3 Awareness, education and training | Yes | Employees are a key security control | R-03/R-15 | Implemented |
| A.6.4 Disciplinary process | Yes | Security violations require defined handling | R-15 | Implemented |
| A.6.5 Responsibilities after termination | Yes | Access must be removed when employment ends | R-01 | Implemented |
| A.6.6 Confidentiality/NDA | Yes | Employees and contractors handle confidential information | R-06 | Implemented |
| A.6.7 Remote working | Yes | Startup employees may access systems remotely | R-16 | Implemented |
| A.6.8 Event reporting | Yes | Employees need a mechanism to report security events | R-09 | Implemented |
3. Physical Controls
For this startup, we assume:
The startup does not own or operate its own data center. Production infrastructure is hosted by AWS.
However, this does not automatically mean all physical controls are irrelevant. The organization still has offices, laptops, equipment and off-premises assets. AWS-related responsibilities also need to be considered through the cloud/supplier relationship.
| Control | Applicable | Why Applicable | Status |
|---|---|---|---|
| A.7.1 Physical security perimeters | Yes | Applies to company-controlled premises | Implemented |
| A.7.2 Physical entry | Yes | Office access requires protection | Implemented |
| A.7.3 Securing offices/rooms/facilities | Yes | Company facilities contain information/assets | Implemented |
| A.7.4 Physical security monitoring | Yes | Relevant to company-controlled facilities | Implemented |
| A.7.5 Physical/environmental threats | Yes | Company equipment requires protection | Implemented |
| A.7.6 Working in secure areas | Yes | Sensitive areas/information require protection | Implemented |
| A.7.7 Clear desk/screen | Yes | Employees handle confidential information | Implemented |
| A.7.8 Equipment siting/protection | Yes | Laptops/equipment require protection | Implemented |
| A.7.9 Assets off-premises | Yes | Employees may work outside offices | Implemented |
| A.7.10 Storage media | Yes | Removable/storage media may contain information | Partial |
| A.7.11 Supporting utilities | Yes | Applies to company premises; AWS responsibility addressed separately | Implemented |
| A.7.12 Cabling security | Yes | Relevant to company-controlled infrastructure | Implemented |
| A.7.13 Equipment maintenance | Yes | Equipment must be securely maintained | Implemented |
| A.7.14 Secure disposal/re-use | Yes | Laptops and storage devices require secure disposal | Implemented |
4. Technological Controls — AWS SaaS
This is the most important section for our example.
| Control | Applicable | Why Applicable | Risk | Status |
|---|---|---|---|---|
| A.8.1 User endpoint devices | Yes | Developers/admins use laptops to access systems | R-16 | Implemented |
| A.8.2 Privileged access rights | Yes | AWS admins have high-impact access | R-01 | Implemented |
| A.8.3 Information access restriction | Yes | Customer information must be restricted | R-06 | Implemented |
| A.8.4 Access to source code | Yes | Source code is critical IP | R-17 | Implemented |
| A.8.5 Secure authentication | Yes | AWS/GitHub/corporate accounts require strong authentication | R-01 | Implemented |
| A.8.6 Capacity management | Yes | SaaS availability depends on AWS capacity | R-10 | Implemented |
| A.8.7 Protection against malware | Yes | Endpoints and systems face malware risk | R-18 | Implemented |
| A.8.8 Technical vulnerability management | Yes | AWS/application dependencies require vulnerability management | R-19 | Implemented |
| A.8.9 Configuration management | Yes | AWS resources require secure configurations | R-20 | Implemented |
| A.8.10 Information deletion | Yes | Customer/company information must be securely deleted | R-21 | Partial |
| A.8.11 Data masking | Yes | Production data should be protected when used in non-production | R-06 | Partial |
| A.8.12 Data leakage prevention | Yes | Customer data/source code require protection | R-06 | Partial |
| A.8.13 Information backup | Yes | Customer data and critical systems require recovery | R-22 | Implemented |
| A.8.14 Redundancy | Yes | Critical SaaS services require availability mechanisms | R-10 | Implemented |
| A.8.15 Logging | Yes | AWS and application activity needs logging | R-01/R-09 | Implemented |
| A.8.16 Monitoring activities | Yes | Security events need detection | R-09 | Implemented |
| A.8.17 Clock synchronization | Yes | Accurate timestamps support investigation | R-09 | Implemented |
| A.8.18 Privileged utility programs | Yes | Admin utilities can affect production | R-01 | Implemented |
| A.8.19 Software installation | Yes | Production changes require control | R-20 | Implemented |
| A.8.20 Network security | Yes | AWS network infrastructure requires protection | R-23 | Implemented |
| A.8.21 Network services security | Yes | SaaS depends on secure network services | R-23 | Implemented |
| A.8.22 Network segregation | Yes | Production/dev/test environments require separation | R-23/R-24 | Implemented |
| A.8.23 Web filtering | Yes | Relevant to corporate endpoint internet access | R-18 | Partial |
| A.8.24 Use of cryptography | Yes | Customer data and communications require protection | R-06 | Implemented |
| A.8.25 Secure development lifecycle | Yes | Company develops its SaaS product | R-17/R-19 | Implemented |
| A.8.26 Application security requirements | Yes | SaaS features require security requirements | R-17 | Implemented |
| A.8.27 Secure architecture/engineering | Yes | AWS architecture must incorporate security | R-20/R-23 | Implemented |
| A.8.28 Secure coding | Yes | Internal developers write application code | R-17/R-19 | Implemented |
| A.8.29 Security testing | Yes | Code/infrastructure changes require testing | R-19 | Implemented |
| A.8.30 Outsourced development | Conditional | Applicable if external developers contribute code | R-17 | Planned/Conditional |
| A.8.31 Dev/test/prod separation | Yes | Customer production data must be separated | R-24 | Implemented |
| A.8.32 Change management | Yes | AWS/application changes can affect security | R-20 | Implemented |
| A.8.33 Test information | Yes | Test data can contain sensitive information | R-24 | Partial |
| A.8.34 Protection during audit/testing | Yes | Testing must avoid unacceptable production impact | R-25 | Implemented |
5. Now Let’s Connect the SoA to the Risk Register
This is the part I would emphasize heavily in your MAE educational material.
Risk R-01
Unauthorized access to AWS production
Initial risk:
Likelihood 4 × Impact 5 = 20 — Critical
Treatment
Reduce
Controls
A.5.15 Access Control
↓
A.5.16 Identity Management
↓
A.5.17 Authentication Information
↓
A.5.18 Access Rights
↓
A.8.2 Privileged Access Rights
↓
A.8.5 Secure Authentication
↓
A.8.15 Logging
↓
A.8.16 MonitoringImplementation
- AWS IAM
- MFA
- Least privilege
- IAM roles
- Privileged access review
- CloudTrail
- CloudWatch
- Access approval
- Joiner/mover/leaver process
Evidence
- IAM configuration
- MFA report
- Access review
- CloudTrail configuration
- CloudWatch alerts
- User access approvals
Residual risk
Example:
Likelihood 2 × Impact 5 = 10 — High
Then management evaluates the residual risk against the organization’s risk acceptance criteria.
6. Another Complete Example
R-02 — Customer Data Exposure
Asset: Customer database and documents
Threat: Unauthorized disclosure
Vulnerability: Excessive permissions / incorrect configuration
Initial risk: 16 — Critical
Treatment
Reduce.
Applicable controls
| SoA Control | Implementation |
|---|---|
| A.5.12 Classification | Customer data classified |
| A.5.15 Access control | Access restricted |
| A.5.18 Access rights | Periodic review |
| A.5.23 Cloud services | AWS security requirements |
| A.8.3 Access restriction | Database/storage restrictions |
| A.8.12 Data leakage prevention | DLP/technical measures |
| A.8.15 Logging | Access logging |
| A.8.16 Monitoring | Security monitoring |
| A.8.24 Cryptography | Encryption |
AWS implementation
RDS
→ Encryption
→ Security groups
→ Restricted access
→ Backup
S3
→ Block public access
→ Bucket policies
→ Encryption
→ Logging
→ Access monitoring
Evidence
- AWS configuration
- IAM policies
- S3 configuration
- RDS configuration
- Encryption settings
- Access review
- Security monitoring
7. The SoA Should Also Contain Non-Annex-A Controls
This is an important point for your MAE framework.
Suppose the SaaS startup decides that:
All production deployments must go through an approved CI/CD pipeline.
That may be an organization-specific control derived from the startup’s risk treatment.
It does not have to be an Annex A control to be necessary.
It should still be included in the SoA if it is one of the controls the organization determined necessary for its ISMS. ISO’s Auditing Practices Group specifically notes that necessary controls can be organization-designed or sourced elsewhere, and such necessary controls must be reflected in the SoA.
For example:
| Internal Control ID | Control | Source | Risk | Status |
|---|---|---|---|---|
| ORG-01 | Production deployment only through approved CI/CD pipeline | Organization | R-20 | Implemented |
| ORG-02 | Quarterly AWS privileged access review | Organization | R-01 | Implemented |
| ORG-03 | Annual independent penetration test | Organization/customer requirement | R-19 | Implemented |
| ORG-04 | Customer security questionnaire management | Customer requirement | R-26 | Implemented |
| ORG-05 | Security review before major architecture changes | Organization | R-20 | Implemented |
This makes the SoA much more realistic.
8. Final Architecture of the SoA
For a real MAE client, I would therefore build the spreadsheet around these columns:
| Column | Purpose |
|---|---|
| Control ID | ISO / internal control reference |
| Control Name | Control description |
| Control Source | Annex A / internal / legal / contractual |
| Applicable | Yes / No |
| Applicability Justification | Why it is relevant |
| Risk ID | Link to risk register |
| Risk Description | Risk being addressed |
| Treatment | Reduce / avoid / share / retain |
| Implementation Status | Implemented / Partial / Planned |
| Control Owner | Responsible person |
| Implementation Description | How the control works |
| Evidence | Proof of operation |
| Residual Risk | Remaining risk |
| Review Frequency | Monthly / quarterly / annual |
| Last Review | Date |
| Remarks | Additional information |
So the complete MAE model becomes:
Business Context
↓
ISMS Scope
↓
Asset Register
↓
Risk Assessment
↓
Risk Treatment Plan
↓
Necessary Controls
↓
Compare Against Annex A
↓
Statement of Applicability
↓
Control Implementation
↓
Evidence
↓
Internal Audit
↓
Residual Risk
↓
Management Review
This is much closer to how an actual ISO 27001 engagement should work than starting with a blank 93-control checklist. ISO’s guidance specifically describes Annex A as a comparison/foundational check against the risk-treatment results, rather than a comprehensive mandatory checklist from which every organization must simply select controls