REFERENCE

ISO 27001 Annex A Controls Explained in Plain English

The complete plain-English guide to ISO 27001's 93 Annex A controls. Learn what each control actually means for your startup and which ones you can skip.

15 min read · Mar 01, 2026

Annex A contains 93 security controls. That sounds overwhelming until you realize most don’t apply to your startup.

This guide translates each control from “auditor-speak” into “what this actually means for my business.” We’ll tell you which controls matter, which you can skip, and how to implement the ones that do.

The big picture: what Annex A actually is

Annex A is a reference list of security controls. Think of it as a menu—you pick what applies to your organization and justify why you’re skipping the rest.

The 93 controls are organized into 4 themes:

  • Organizational controls (37 controls) - Policies, people, and processes
  • People controls (8 controls) - HR and security awareness
  • Physical controls (14 controls) - Office and equipment security
  • Technological controls (34 controls) - Systems and data security

For a typical SaaS startup, you’ll implement about 40-50 of these 93 controls.

A.5: Information Security Policies (2 controls)

A.5.1: Policies for information security

What it says: Create policies to direct your security efforts What it means: Write down your security rules and decisions Startup reality: You already make security decisions—just document them Implementation: 3-5 core policies covering access, incident response, and acceptable use

A.5.37: Documented operating procedures

What it says: Document procedures for key security activities What it means: Write down how you do important security tasks Startup reality: Your team knows how to do things—write it down Implementation: Document backup procedures, access reviews, incident response

A.6: Organization of Information Security (3 controls)

A.6.1: Information security roles and responsibilities

What it says: Define who does what for security What it means: Everyone knows their security responsibilities Startup reality: You already have roles—just clarify security parts Implementation: Update job descriptions to include security responsibilities

A.6.2: Segregation of duties

What it says: Don’t let one person do everything What it means: Separate critical security functions Startup reality: Hard with small teams, but focus on high-risk areas Implementation: Different people for code deployment and database access

A.6.3: Management commitment

What it says: Leadership must support security What it means: Founders must care about security Startup reality: If you’re reading this, you already do Implementation: Regular security discussions in leadership meetings

A.7: Human Resource Security (6 controls)

A.7.1: Screening

What it says: Check backgrounds before hiring What it means: Know who you’re hiring Startup reality: You already do basic screening Implementation: Document your hiring process and reference checks

A.7.2: Information security awareness, education and training

What it says: Train people on security What it means: Teach your team security basics Startup reality: You already discuss security—make it systematic Implementation: Quarterly security discussions, phishing awareness

A.7.3: Disciplinary process

What it says: Have consequences for security violations What it means: People know what happens if they break security rules Startup reality: You already have employee discipline—extend to security Implementation: Add security violations to your employee handbook

A.8: Asset Management (10 controls)

A.8.1: Inventory of assets

What it says: Know what you have What it means: List your important systems and data Startup reality: You know your stack—write it down Implementation: Document production systems, databases, and key data

A.8.2: Classification of information

What it says: Label data by sensitivity What it means: Know what data is most important Startup reality: You already know what’s critical Implementation: Classify data as public, internal, confidential, restricted

A.8.3: Acceptable use

What it says: Define proper use of systems What it means: Rules for using company resources Startup reality: You have unwritten rules—write them down Implementation: Policy on acceptable use of laptops, software, and data

A.9: Access Control (14 controls)

A.9.1: Access control policy

What it says: Rules for who can access what What it means: Define access principles Startup reality: You already follow least privilege Implementation: Document your access control principles

A.9.2: User access management

What it says: Manage user access properly What it means: Add/remove access as people join/leave Startup reality: You already do this—make it systematic Implementation: Formal onboarding/offboarding checklists

A.9.3: User responsibilities

What it says: Users must protect their access What it means: People shouldn’t share passwords Startup reality: Common sense—document it Implementation: Policy on password sharing and account security

A.9.4: System access control

What it says: Control access to systems What it means: Technical access controls Startup reality: You already use AWS IAM, MFA Implementation: Ensure MFA everywhere, regular access reviews

A.10: Cryptography (2 controls)

A.10.1: Encryption controls

What it says: Use encryption properly What it means: Encrypt sensitive data Startup reality: You already use HTTPS, database encryption Implementation: Document your encryption practices

A.10.2: Key management

What it says: Protect encryption keys What it means: Don’t lose or expose encryption keys Startup reality: You already use secret managers Implementation: Document key rotation and storage procedures

A.11: Physical and Environmental Security (15 controls)

A.11.1: Physical security perimeter

What it says: Secure your office What it means: Lock doors, control access Startup reality: Cloud-hosted? Skip most of these Implementation: If you have an office, basic access control

A.11.2: Physical entry

What it says: Control who enters What it means: Visitor logs, access cards Startup reality: Remote team? Skip this Implementation: Document visitor procedures if you have an office

A.11.3: Securing offices, rooms and facilities

What it says: Secure physical spaces What it means: Locks, cameras, alarms Startup reality: Cloud startup? Skip most Implementation: Basic office security if applicable

A.12: Operations Security (14 controls)

A.12.1: Operational procedures and responsibilities

What it says: Document how you operate What it means: Write down operational procedures Startup reality: You have processes—document them Implementation: Document backup, deployment, monitoring procedures

A.12.2: Protection from malware

What it says: Prevent malware What it means: Antivirus, security scanning Startup reality: You already use security tools Implementation: Document your malware protection approach

A.12.3: Backup

What it says: Back up your data What it means: Regular, tested backups Startup reality: You already back up databases Implementation: Document backup procedures and test restores

A.12.4: Logging and monitoring

What it says: Watch what happens What it means: Log important events Startup reality: You already have some logging Implementation: Document what you log and review logs regularly

A.13: Communications Security (7 controls)

A.13.1: Network security controls

What it says: Secure your networks What it means: Firewalls, network segmentation Startup reality: You already use VPC, security groups Implementation: Document your network security setup

A.13.2: Information transfer

What it says: Protect data in transit What it means: Encrypt communications Startup reality: You already use HTTPS everywhere Implementation: Document your encryption standards

A.14: System Acquisition, Development and Maintenance (13 controls)

A.14.1: Security requirements

What it says: Consider security in development What it means: Think about security when building Startup reality: You already consider security—be systematic Implementation: Add security requirements to your development process

A.14.2: Security in development

What it says: Secure development practices What it means: Code reviews, security testing Startup reality: You already do code reviews Implementation: Document your secure development practices

A.14.3: Test data

What it says: Protect test data What it means: Don’t use real data in testing Startup reality: You probably already do this Implementation: Document your test data approach

A.15: Supplier Relationships (5 controls)

A.15.1: Supplier assessment

What it says: Check your vendors What it means: Due diligence on third parties Startup reality: You already vet important vendors Implementation: Document your vendor assessment process

A.15.2: Supplier agreements

What it says: Security requirements in contracts What it means: Make vendors meet your security standards Startup reality: You already have contracts—add security clauses Implementation: Review key vendor contracts for security requirements

A.16: Information Security Incident Management (7 controls)

A.16.1: Incident management

What it says: Handle security incidents What it means: Plan for when things go wrong Startup reality: You already think about this—plan it Implementation: Create incident response procedures

A.16.2: Detection and response

What it says: Find and respond to incidents What it means: Monitor for problems Startup reality: You already have some monitoring Implementation: Document incident detection and response procedures

A.17: Information Security Aspects of Business Continuity Management (4 controls)

A.17.1: Business continuity planning

What it says: Plan for disasters What it means: How to keep running during problems Startup reality: You already think about this—document it Implementation: Document your business continuity procedures

A.17.2: Redundancy

What it says: Have backups for critical systems What it means: Don’t have single points of failure Startup reality: You already have some redundancy Implementation: Document your redundancy approach

A.18: Compliance (8 controls)

A.18.1: Legal requirements

What it says: Follow applicable laws What it means: Know and follow relevant regulations Startup reality: You already try to be compliant Implementation: Document relevant laws and how you comply

A.18.2: Intellectual property

What it says: Protect intellectual property What it means: Don’t steal software or data Startup reality: Common sense—document it Implementation: Policy on software licensing and IP protection

Which controls to skip (and why)

For most SaaS startups, you can skip or justify exclusion of these controls:

Physical security controls (A.11)

Why skip: Cloud-hosted infrastructure means your cloud provider handles physical security Justification: “Physical security is managed by AWS/GCP/Azure, which is SOC 2 certified”

Many organizational controls (A.6)

Why skip: Small team means some separation of duties isn’t practical Justification: “Small team size makes complete segregation impractical; compensating controls include peer review and management oversight”

Extensive business continuity (A.17)

Why skip: Cloud provider provides high availability Justification: “Cloud infrastructure provides built-in redundancy; business continuity focuses on data backup and recovery”

Implementation priority for startups

Phase 1 (Month 1): Foundation

  • A.5.1: Information security policies
  • A.8.1: Asset inventory
  • A.9.1: Access control policy
  • A.12.3: Backup procedures

Phase 2 (Month 2): Operations

  • A.9.2: User access management
  • A.12.1: Operational procedures
  • A.12.4: Logging and monitoring
  • A.14.2: Security in development

Phase 3 (Month 3): Processes

  • A.7.2: Security awareness
  • A.16.1: Incident management
  • A.15.1: Supplier assessment
  • A.18.1: Legal requirements

The startup approach to Annex A

  1. Don’t try to do everything - Focus on what applies to your business
  2. Document what you already do - You’re probably 40% compliant already
  3. Use cloud provider compliance - Leverage your provider’s certifications
  4. Focus on documentation - The gap is usually paperwork, not implementation
  5. Be practical - Implement controls that make business sense

Quick reference: The 20 controls that matter most

For a typical SaaS startup, these 20 controls cover 80% of what matters:

  1. A.5.1 - Information security policies
  2. A.6.1 - Security roles and responsibilities
  3. A.7.2 - Security awareness training
  4. A.8.1 - Asset inventory
  5. A.8.2 - Information classification
  6. A.9.1 - Access control policy
  7. A.9.2 - User access management
  8. A.9.4 - System access control
  9. A.10.1 - Encryption controls
  10. A.12.1 - Operational procedures
  11. A.12.3 - Backup procedures
  12. A.12.4 - Logging and monitoring
  13. A.13.1 - Network security controls
  14. A.14.2 - Security in development
  15. A.15.1 - Supplier assessment
  16. A.16.1 - Incident management
  17. A.17.1 - Business continuity planning
  18. A.18.1 - Legal requirements
  19. A.5.37 - Documented procedures
  20. A.6.3 - Management commitment

Focus on these first, then add others as needed.

The bottom line

Annex A looks intimidating, but most controls are common-sense security practices you’re already following. The key is:

  1. Identify what applies to your startup
  2. Document what you already do
  3. Fill the gaps systematically
  4. Use your cloud provider’s compliance

You don’t need to become a security expert. You need to translate good security practices into documented processes.

Ready to see which Annex A controls you’ve already implemented? Get your personalized control assessment in 15 minutes →

Know where you stand. Decide what's next.

15 minutes. No sales call. Just your compliance picture.

Your Headstart Begins Now