You just found out your enterprise prospect needs you to be ISO 27001 certified. You start reading the standard and hit Annex A: 93 controls. Your first reaction is probably somewhere between “that’s a lot” and “we’re a 40-person startup, not a bank.”
Take a breath. The number sounds worse than it is. Most of those controls map to things you’re probably already doing, and a good chunk won’t even apply to your setup.
Here’s what the 93 controls actually are, how they’re organized, and which ones matter for a SaaS startup.
The Short Answer: 93 Controls in 4 Themes
ISO/IEC 27001:2022 lists 93 controls in Annex A. They’re grouped into four themes:
| Theme | Controls | What It Covers |
|---|---|---|
| Organizational | 37 | Policies, roles, supplier management, incident management, business continuity |
| People | 8 | Screening, awareness, terms of employment, remote working |
| Physical | 14 | Secure areas, equipment protection, clear desk, media handling |
| Technological | 34 | Access control, cryptography, logging, network security, secure development |
That’s it. Four groups instead of the fourteen domains in the old version.
What Changed from 2013 to 2022
If you’ve seen older ISO 27001 resources online, they reference 114 controls in 14 domains. That was the 2013 version. Here’s what happened in the 2022 update:
Controls went from 114 to 93. Not because controls were removed, but because many were merged. For example, the 2013 version had separate controls for “information transfer policies” and “information transfer agreements.” The 2022 version combines them into one control (A.5.14 Information Transfer).
14 domains became 4 themes. The old structure (Access Control, Cryptography, Operations Security, etc.) was reorganized into the four themes above. This makes it easier to assign ownership: your HR team handles People controls, your IT team handles Technological, and so on.
11 new controls were added. These reflect how companies actually operate now:
- A.5.7 Threat Intelligence - Collecting and analyzing threat information relevant to your business
- A.5.23 Information Security for Cloud Services - Because everyone uses AWS/GCP/Azure now
- A.5.30 ICT Readiness for Business Continuity - Making sure your tech stack can recover from disruption
- A.7.4 Physical Security Monitoring - CCTV and surveillance for physical locations
- A.8.9 Configuration Management - Maintaining secure baseline configurations
- A.8.10 Information Deletion - Proper data deletion when retention periods expire
- A.8.11 Data Masking - Anonymizing or pseudonymizing data
- A.8.12 Data Leakage Prevention - DLP measures
- A.8.16 Monitoring Activities - Security monitoring and anomaly detection
- A.8.23 Web Filtering - Controlling access to external websites
- A.8.28 Secure Coding - Secure development practices baked into your SDLC
If you’re starting fresh, you’ll certify against the 2022 version. If you were already certified under 2013, the transition deadline was October 2025.
Which Controls Actually Matter for a SaaS Startup
Here’s where it gets practical. Not all 93 controls carry equal weight for a cloud-native SaaS company. Some are critical. Some are checkbox exercises. Some don’t apply at all.
High Priority: Get These Right
Access Control (A.8.2-A.8.5) - Who can access what in your production environment. This is where auditors spend the most time. You need role-based access, least privilege, and regular access reviews. If your entire engineering team has root access to production, this is your first fix.
Cryptography (A.8.24) - Encryption at rest, encryption in transit, key management. If you’re running on AWS or GCP, most of this is handled by managed services, but you need to document it.
Logging and Monitoring (A.8.15-A.8.16) - Audit logs for who did what, when. Application logs, infrastructure logs, access logs. You need centralized logging and someone actually looking at it, not just storing it.
Secure Development (A.8.25-A.8.28, A.8.31-A.8.33) - Secure SDLC, code reviews, testing, separation of dev/test/prod environments. If you’re already doing PR reviews and have a CI/CD pipeline with staging, you’re most of the way there.
Incident Management (A.5.24-A.5.28) - How you detect, respond to, and learn from security incidents. You need a documented incident response plan. If you’ve never had an incident, you still need the plan and ideally a tabletop exercise to test it.
Supplier Security (A.5.19-A.5.22) - How you assess and manage the security of your third-party vendors. AWS, Stripe, your CI/CD tool, your monitoring stack. You don’t need to audit each one, but you need to track who has access to your data and review their security posture.
Information Security Policies (A.5.1) - Your overarching security policy. Auditors expect a concise policy signed by leadership, reviewed annually. Don’t write a 50-page document nobody reads.
Medium Priority: Important but Straightforward
People Controls (A.6.1-A.6.8) - Background screening for new hires, security awareness training, terms in employment contracts, exit procedures. Most startups have pieces of this in their HR process already. You just need to formalize and document it.
Business Continuity (A.5.29-A.5.30) - Disaster recovery plans, RTO/RPO targets, backup testing. If your infrastructure is on a cloud provider with multi-AZ deployment, your starting position is strong. Document it and test restores periodically.
Cloud Security (A.5.23) - Since this is a new control in 2022, auditors pay attention to it. Document your shared responsibility model, your cloud provider selection criteria, and how you configure cloud services securely.
Low Priority or Likely Not Applicable
Physical Security (A.7.1-A.7.14) - If your team works remotely or from co-working spaces and your infrastructure is 100% cloud, many physical controls won’t apply. You can’t control the physical security of a WeWork. You still need to address equipment security (laptops, mobile devices) and clear desk/screen policies.
Media Handling (A.7.10) - Storage media, transport of media, disposal of media. If you’re fully cloud-native with no on-premise servers or physical backup tapes, this control is either not applicable or limited to laptop hard drive encryption and secure disposal.
Paper-Based Controls - Some controls reference physical documents (clear desk, secure disposal of paper records). If your company is paperless, these are marked as not applicable with a simple justification.
Statement of Applicability: Your Key Document
The Statement of Applicability (SoA) is where you formally declare which of the 93 controls apply to your organization and which don’t. It’s one of the most important documents in your ISMS.
For each control, you state:
- Applicable or Not Applicable - with justification
- Implementation Status - implemented, partially implemented, or planned
- How It’s Implemented - reference to the specific policy, tool, or process
- Risk Treatment Link - which risk(s) the control addresses
Here’s what a typical SoA entry looks like for a startup:
A.7.4 Physical Security Monitoring - Not Applicable. Justification: The organization operates fully remotely with cloud-hosted infrastructure. No company-owned physical premises require monitoring.
A.8.24 Use of Cryptography - Applicable. Implementation: All data at rest encrypted using AES-256 via AWS KMS. All data in transit protected by TLS 1.2+. Key rotation policy documented in CR-POL-003.
Most SaaS startups end up with 60-75 controls marked as applicable. The exact number depends on your setup: whether you have an office, whether you handle sensitive personal data, whether you have on-premise components, and so on.
Common “Not Applicable” Controls for SaaS Startups
- A.7.1-A.7.2 (Physical security perimeters and entry) if fully remote with no office
- A.7.3 (Securing offices, rooms, and facilities) if using co-working spaces only
- A.7.4 (Physical security monitoring) if no owned premises
- A.7.7 (Clear desk and clear screen) partially applicable, often limited to screen lock policies
- A.7.9-A.7.10 (Security of assets off-premises, storage media) if fully cloud-native
The key word is “justification.” An auditor won’t challenge a “Not Applicable” marking if your justification makes sense. They will challenge it if you mark something as not applicable just because you haven’t implemented it yet. “We don’t do this” is not the same as “this doesn’t apply to us.”
How to Approach the 93 Controls Without Losing Your Mind
If you’re a CTO staring at a spreadsheet of 93 controls for the first time, here’s a practical sequence:
Step 1: Map what you already have. Go through each control and check what’s already in place. Most Series A+ startups already cover 30-40% of controls through existing practices (code reviews, cloud security defaults, access management, etc.). You just haven’t documented them.
Step 2: Identify not-applicable controls. For a cloud-native remote startup, you can usually mark 15-25 controls as not applicable. This immediately reduces your work.
Step 3: Group the remaining gaps by effort. Some gaps are policy-only (write a document). Some need tooling changes. Some need process changes. Sort them by effort and start with the quick wins.
Step 4: Build your SoA alongside your risk assessment. The SoA isn’t an afterthought. It’s directly tied to your risk treatment plan. Each control you select should trace back to a risk you’ve identified.
Step 5: Don’t write policies from scratch. Use templates. Adapt them to your context. A 2-page access control policy that reflects how your team actually works is worth more than a 15-page copy-paste that nobody follows.
If you’ve been through a SOC 2 Type I or Type II, you’ll find about 70% of the work overlaps. Your access controls, change management, logging, and vendor management carry over directly.
For a detailed walkthrough of the full certification process, timeline, and costs, see our guide on ISO 27001 certification for Bangalore startups.
Where Startups Get Stuck
The controls themselves aren’t where most startups struggle. The hard parts are:
Risk Assessment: ISO 27001 is risk-based. You can’t just implement controls randomly. You need a risk assessment that identifies threats to your information assets, evaluates likelihood and impact, and then maps controls to those risks. This is the foundation of the entire ISMS.
Documentation overhead: You need policies, procedures, records, and evidence. For a startup used to moving fast with minimal documentation, this feels heavy. The trick is writing lean documents that match how you actually operate, not aspirational documents that describe a process nobody follows.
Internal audit: Before your certification audit, you need an internal audit. Someone independent (not the person who built the ISMS) needs to review it. This is where most startups realize their documentation has gaps.
Management review: Leadership needs to formally review the ISMS at least annually. This means a meeting with documented minutes covering security metrics, audit results, risk status, and improvement actions.
Getting Started Without Over-Engineering It
If you’re early in the process and the 93 controls feel overwhelming, start with a focused assessment. Understand where you stand, which controls apply, and what the gaps look like before committing to the full certification project.
Our Security on Demand session is built for exactly this. For INR 9,999, you get 4 hours of founder-led consulting where we map your current state against ISO 27001 controls, identify your likely SoA scope, and build a prioritized roadmap. If you don’t find it useful, we refund the full amount. If you continue with us for the certification project, the amount comes off your invoice.
For ongoing audit prep and compliance support, check out our Audit and Compliance services.
The 93 controls aren’t a checklist to fear. They’re a structured way to think about security. Once you understand how they map to your actual infrastructure and processes, the path to certification gets a lot clearer.