ISO 27001 Annex A controls are the heart of your Information Security Management System (ISMS). These 93 security controls (in the 2022 version) cover everything from access management and encryption to incident response and vendor risk management.
If you're a startup preparing for ISO 27001 certification, you don't need to implement all 93 controls — but you do need to document why each control is or isn't applicable to your organization. This guide explains what Annex A controls are, breaks down the control categories with practical examples, identifies which controls matter most for startups, and shows how automation tools can simplify evidence collection.
What Are ISO 27001 Annex A Controls?
ISO 27001 has two main parts:
- The standard itself (Clauses 4–10): Defines the requirements for establishing, implementing, maintaining, and improving an ISMS
- Annex A: A catalog of 93 security controls that organizations can implement based on their risk assessment
Key point: ISO 27001 doesn't require you to implement all 93 Annex A controls. Instead, you must:
- Conduct a risk assessment to identify threats and vulnerabilities
- Select controls from Annex A (or define your own) to address identified risks
- Document why each Annex A control is applicable or not applicable in your Statement of Applicability (SoA)
- Implement the controls marked as applicable
- Collect evidence that controls are operating effectively
The Statement of Applicability is a mandatory document that auditors will review carefully. A well-justified SoA explains your risk-based approach and demonstrates that you've thought through each control category.
ISO 27001 Annex A Control Categories (2022 Version)
The 2022 update consolidated controls from 114 (in the 2013 version) down to 93 and reorganized them into four themes: Organizational, People, Physical, and Technological. Here's the breakdown:
Organizational Controls (37 controls)
These controls establish governance, policies, and processes for managing information security across the organization.
Examples of organizational controls:
- A.5.1 Information security policies: A documented, leadership-approved policy that defines your approach to information security
- A.5.7 Threat intelligence: Monitoring security advisories, CVE databases, and threat feeds relevant to your technology stack
- A.5.10 Acceptable use of information and assets: Rules for how employees can use company devices, cloud services, and customer data
- A.5.19 Information security in supplier relationships: Vendor risk assessments, security questionnaires, and contract requirements for third-party services
- A.5.23 Cloud services use: Policies and controls for using cloud infrastructure (AWS, GCP, Azure) and SaaS tools (Slack, GitHub, Salesforce)
- A.5.30 Business continuity and disaster recovery: Plans for maintaining operations during incidents, outages, or data loss events
Why these matter for startups: Even small companies rely on dozens of SaaS tools and cloud providers. Organizational controls ensure you've assessed vendor risks, defined acceptable use policies, and have a plan when things go wrong.
Practical example: A Series A SaaS startup uses 40+ third-party services. Their A.5.19 control includes a vendor inventory spreadsheet, security questionnaires for critical vendors (AWS, Stripe, Auth0), and contract clauses requiring SOC 2 or ISO 27001 certification for any vendor processing customer data.
People Controls (8 controls)
These controls address human risk — hiring, training, and offboarding employees securely.
Examples of people controls:
- A.6.1 Screening: Background checks for employees and contractors with access to sensitive data or production systems
- A.6.2 Terms and conditions of employment: Confidentiality agreements, acceptable use policies, and security responsibilities included in employment contracts
- A.6.3 Information security awareness, education, and training: Onboarding security training and ongoing awareness programs (phishing simulations, security newsletters)
- A.6.4 Disciplinary process: Procedures for handling security policy violations
- A.6.5 Confidentiality or non-disclosure agreements: NDAs with employees, contractors, and business partners
- A.6.8 Information security event reporting: A clear process for employees to report suspected security incidents, phishing attempts, or policy violations
Why these matter for startups: People are the weakest link in security. A well-trained team that understands security policies and knows how to report suspicious activity prevents most breaches.
Practical example: A 25-person startup implements A.6.3 by requiring all new hires to complete a 30-minute security awareness training module during onboarding (tracked in their LMS). They send quarterly phishing simulations and publish a monthly "Security Tips" Slack post.
Physical Controls (14 controls)
These controls protect physical infrastructure — offices, data centers, and hardware.
Examples of physical controls:
- A.7.1 Physical security perimeters: Controlled access to offices and server rooms (key cards, visitor logs)
- A.7.2 Physical entry controls: Badge access systems, visitor sign-in sheets, and escort policies
- A.7.4 Physical security monitoring: Security cameras, alarm systems, or third-party security services
- A.7.7 Clear desk and clear screen: Policies requiring employees to lock screens when away from desks and secure documents when not in use
- A.7.10 Storage media: Secure handling, encryption, and disposal of USB drives, backup tapes, and hard drives
- A.7.14 Secure disposal of equipment: Wiping or destroying hard drives, laptops, and phones before disposal
Why these matter for startups: If you're a cloud-native startup with no on-premise servers, many physical controls are "not applicable" — but you still need to address office security, laptop encryption, and secure disposal processes.
Practical example: A fully remote startup marks most physical controls as "not applicable" in their Statement of Applicability. However, they implement A.7.7 (clear screen policy) by requiring full-disk encryption on all company laptops and auto-lock after 5 minutes of inactivity.
Technological Controls (34 controls)
These are the technical safeguards — encryption, access controls, logging, vulnerability management, and secure development practices.
Examples of technological controls:
- A.8.2 Privileged access rights: Managing admin access to production systems, databases, and cloud infrastructure
- A.8.3 Information access restriction: Role-based access control (RBAC) ensuring employees only access data necessary for their role
- A.8.5 Secure authentication: Multi-factor authentication (MFA) for email, VPN, cloud services, and production systems
- A.8.8 Management of technical vulnerabilities: Regular vulnerability scanning, patch management, and remediation tracking
- A.8.9 Configuration management: Hardened server configurations, secure default settings, and infrastructure-as-code practices
- A.8.10 Information deletion: Processes for securely deleting customer data when requested (GDPR right to erasure)
- A.8.16 Monitoring activities: Centralized logging, SIEM tools, and alerting on suspicious activity
- A.8.23 Web filtering: Blocking malicious websites and phishing domains
- A.8.24 Cryptography: Encryption of data at rest and in transit (TLS, AES-256, encrypted databases)
- A.8.26 Application security requirements: Secure coding standards, OWASP top 10 awareness, and security requirements in your development lifecycle
- A.8.28 Secure coding: Code review processes, static analysis tools, and security testing in CI/CD pipelines
- A.8.31 Separation of development, test, and production environments: Ensuring developers can't accidentally deploy untested code to production or access live customer data in dev/staging
Why these matter for startups: Technological controls are where most startups already have strong practices. If you use AWS/GCP/Azure, have a CI/CD pipeline, and enforce MFA, you're closer to compliance than you think.
Practical example: A fintech startup implements A.8.28 (secure coding) by:
- Requiring peer code review for all pull requests (enforced in GitHub branch protection rules)
- Running static analysis tools (SonarQube, Snyk) in CI/CD to catch vulnerabilities before deployment
- Conducting quarterly secure coding training for the engineering team
- Tracking remediation of high/critical vulnerabilities in Jira
Which Annex A Controls Are Most Important for Startups?
Not all controls are equally important. Here are the controls that auditors scrutinize most for SaaS startups and that provide the most security value:
Must-Implement Controls for Startups
| Control | Why It Matters | Implementation Effort |
|---|---|---|
| A.5.1 Information security policies | Foundational document that auditors will review first | Low (use template, customize for your org) |
| A.8.2 Privileged access rights | Prevents unauthorized access to production systems | Medium (implement RBAC, MFA for admins) |
| A.8.3 Information access restriction | Core data protection control | Medium (SSO + role-based access) |
| A.8.5 Secure authentication | Prevents account takeover and credential theft | Low (enable MFA on all critical systems) |
| A.8.8 Management of technical vulnerabilities | Protects against known exploits and zero-days | High (requires continuous scanning + patching) |
| A.8.16 Monitoring activities | Enables incident detection and forensic investigation | High (centralized logging, SIEM setup) |
| A.8.24 Cryptography | Protects data in transit and at rest | Medium (TLS everywhere, encrypted databases) |
| A.8.26 Application security requirements | Reduces vulnerabilities in your codebase | Medium (define secure coding standards) |
| A.5.19 Supplier relationship security | Critical for cloud-native startups relying on vendors | Medium (vendor risk assessments) |
| A.6.3 Security awareness training | Reduces phishing, social engineering, and policy violations | Low (use an LMS or platform like KnowBe4) |
Controls That Are Often "Not Applicable" for Cloud-Native Startups
| Control | Why It's Often N/A for Startups |
|---|---|
| A.7.1–A.7.4 Physical security perimeters and monitoring | No on-premise data centers; AWS/GCP/Azure inherit physical controls |
| A.11.1 Utilities (power, cooling, cabling) | Cloud providers manage infrastructure utilities |
| A.11.14 Redundancy of information processing facilities | Cloud providers handle geographic redundancy and failover |
| A.7.10 Storage media (tapes, removable media) | Startups rarely use physical backup tapes or USB drives for production data |
Important: Even if a control is "not applicable," you must justify why in your Statement of Applicability. Auditors want to see thoughtful risk-based decisions, not lazy blanket exclusions.
Common Mistakes When Implementing Annex A Controls
1. Implementing Controls Without Evidence
Having a control in place isn't enough — you need evidence that it's operating effectively.
Bad: "We have multi-factor authentication enabled."
Good: Screenshots showing MFA enforced in AWS IAM, Google Workspace admin console, and GitHub organization settings + logs proving MFA challenges are working.
2. Marking Too Many Controls as "Not Applicable"
Auditors expect most controls to be applicable. If you mark 30+ controls as N/A, you'll need strong justification.
Red flag: Marking A.8.16 (monitoring activities) as N/A because "we're a small startup and don't have a SOC."
Better approach: Implement basic CloudTrail logging, centralize logs in an S3 bucket, and set up alerts for critical events (root account login, failed authentication attempts).
3. Writing Generic Policies Without Implementation Details
Copying policy templates verbatim without customizing them for your tech stack, team size, and risk environment is obvious to auditors.
Bad: "We encrypt data in transit and at rest." (No specifics.)
Good: "All data in transit uses TLS 1.2 or higher. Customer data at rest is encrypted using AWS RDS encryption with AES-256. Encryption keys are managed in AWS KMS with automatic rotation enabled."
4. Not Aligning Controls to Your Risk Assessment
The whole point of Annex A is to address identified risks. Your Statement of Applicability should directly reference threats and vulnerabilities from your risk register.
Example: If your risk assessment identifies "insider threat from privileged users" as a high risk, your SoA should explain how A.8.2 (privileged access rights) and A.8.16 (monitoring) mitigate that risk.
5. Implementing Controls Manually Instead of Automating
Manual evidence collection (taking screenshots, exporting logs, compiling spreadsheets every quarter) is time-consuming and error-prone. Automation platforms continuously collect evidence and alert you when controls drift.
How Vylint Shield Automates Annex A Evidence Collection
Vylint Shield maps your existing tools to ISO 27001 Annex A controls and automatically collects evidence:
| Annex A Control | Vylint Shield Automation |
|---|---|
| A.8.5 Secure authentication | Pulls MFA enforcement settings from AWS IAM, Google Workspace, GitHub, and Okta |
| A.8.2 Privileged access rights | Tracks admin role assignments and changes in AWS, GCP, and GitHub |
| A.8.28 Secure coding | Monitors pull request reviews, branch protection rules, and security scan results from GitHub |
| A.8.8 Vulnerability management | Aggregates findings from Snyk, Dependabot, and AWS Inspector |
| A.8.16 Monitoring activities | Centralizes CloudTrail logs, application logs, and audit logs with tamper-proof timestamping |
| A.6.3 Security awareness training | Syncs training completion records from your LMS |
| A.5.19 Vendor risk assessments | Tracks vendor SOC 2/ISO 27001 certifications and contract renewal dates |
Instead of scrambling to gather evidence during audit prep, Vylint Shield maintains an always-audit-ready evidence repository.
How to Get Started with Annex A Controls
Step 1: Conduct a Risk Assessment
Identify your assets (customer data, source code, production systems), threats (phishing, ransomware, insider threats), and vulnerabilities (unpatched software, weak access controls).
Step 2: Map Risks to Annex A Controls
For each identified risk, select Annex A controls that mitigate the risk. Document your selections in a Statement of Applicability.
Step 3: Implement Applicable Controls
Prioritize high-risk controls first (authentication, encryption, access management). Use templates for policies, configure technical controls in your cloud environment, and train your team.
Step 4: Collect Evidence Continuously
Set up automated evidence collection so you're always audit-ready. Manual evidence gathering is the slowest part of ISO 27001 prep.
Step 5: Document Your ISMS
Write your ISMS manual, risk register, Statement of Applicability, and control implementation details. Auditors will review these documents during Stage 1.
Step 6: Conduct an Internal Audit
Test your controls before the external audit. Identify gaps, remediate findings, and update documentation.
Step 7: Engage a Certification Body
Book your Stage 1 and Stage 2 audits. If your controls are well-documented and evidence is organized, the audit process is straightforward.
Annex A Controls: Key Takeaways
- 93 controls in the 2022 version, organized into Organizational, People, Physical, and Technological categories
- You don't need to implement all 93 — only the controls justified by your risk assessment
- Your Statement of Applicability is mandatory and must explain why each control is applicable or not
- Evidence is as important as implementation — auditors verify that controls are operating, not just documented
- Startups can mark physical controls as N/A if they're cloud-native, but must justify technological and organizational controls
- Automation tools reduce manual effort by continuously collecting evidence from your existing systems
Automate Annex A Evidence Collection
Vylint Shield pre-maps your cloud infrastructure, SaaS tools, and development workflows to ISO 27001 Annex A controls. This automation significantly reduces the time spent on evidence collection and documentation preparation — helping you arrive at your third-party audit better organized and more audit-ready.
Certification Disclaimer: Vylint Shield is a documentation and audit-readiness platform. We do not perform or issue ISO 27001 certifications. Formal certification requires engagement with an independent, accredited certification body selected by your organization.
Ready to simplify your Annex A compliance? See how Vylint Shield works
About the Author: This guide was written by the Vylint Shield team.
← Back to all posts