ISO 27001 Access Control: Requirements, Controls, and SaaS Implementation

Access control is the practice of ensuring that only authorized individuals can access specific information, systems, and resources — and only to the extent their role requires. In ISO 27001, access control spans multiple Annex A controls and touches nearly every part of a SaaS company’s operations, from employee onboarding to production database administration to customer-facing API authentication.

For SaaS companies, access control is simultaneously the most important and the most complex domain to get right. Your product runs on cloud infrastructure managed by distributed teams. Engineers need access to production systems. Customer success teams need access to customer data for support. Third-party integrations need API credentials. CI/CD pipelines need deployment keys. Each of these access paths must be governed, monitored, and reviewed.

This guide covers every ISO 27001 access control requirement, the specific Annex A controls that apply, and practical implementation guidance for SaaS companies operating on modern cloud platforms.

Relevant Annex A Controls

ISO 27001:2022 reorganized its controls into four themes: Organizational, People, Physical, and Technological. Access control spans the Organizational and Technological themes. Understanding which controls apply — and what each one demands — is the foundation of your access control policy.

Organizational Controls

A.5.15 — Access control The overarching control. It requires that rules governing access to information and other associated assets be established and implemented based on business and information security requirements. This is your access control policy — the document that defines the principles (least privilege, need-to-know, RBAC) that all other access controls implement.

A.5.16 — Identity management The full lifecycle of user identities must be managed. This covers the creation, maintenance, and removal of digital identities. For SaaS companies, this means managing identities across your identity provider (Okta, Azure AD, Google Workspace), cloud platforms, SaaS tools, and internal applications.

A.5.17 — Authentication information Management of authentication information (passwords, tokens, certificates, keys) through their entire lifecycle. This includes initial allocation, secure storage, rotation, and revocation. The control demands that authentication information not be shared between individuals and that default credentials be changed immediately upon provisioning.

A.5.18 — Access rights Access rights must be provisioned, reviewed, modified, and removed in accordance with the access control policy. This is the operational control that implements your RBAC model. It requires a defined process for granting access, a mechanism for adjusting access when roles change, and a defined process for revoking access when it is no longer needed.

Technological Controls

A.8.2 — Privileged access rights Privileged access (administrator accounts, root access, database superuser) must be restricted and controlled. This control requires explicit authorization for privileged access, separation of privileged and regular user accounts, logging of privileged actions, and periodic review of privileged access rights.

A.8.3 — Information access restriction Access to information must be restricted in accordance with the access control policy. This translates to technical enforcement: database access controls, application authorization rules, file system permissions, network segmentation that prevents unauthorized access paths.

A.8.4 — Access to source code Read and write access to source code, development tools, and software configurations must be controlled. For SaaS companies, this means repository access management, branch protection rules, and code review requirements.

A.8.5 — Secure authentication Authentication mechanisms must be appropriate to the sensitivity of the systems and data being accessed. This is where multi-factor authentication (MFA) requirements, single sign-on (SSO), passwordless authentication, and session management come into play.

Building Your Access Control Policy

Your access control policy is the foundation document that defines principles, assigns responsibilities, and sets the requirements that all subsequent procedures and technical controls implement. It should be concise, specific to your organization, and testable. For guidance on policy structure and writing, see our ISO 27001 Policies guide.

Core Principles

Every access control policy should establish these principles:

Principle of least privilege. Users are granted the minimum access rights necessary to perform their job functions. Access is not granted by default — it must be explicitly requested, justified, and approved.

Need-to-know basis. Access to information is restricted to individuals who require it for their specific role. Having a security clearance or seniority does not automatically confer access to all information at that level.

Segregation of duties. Critical functions are divided among multiple individuals to prevent any single person from having end-to-end control over a sensitive process. In SaaS terms: the person who writes code should not be the sole approver of their own deployments to production.

Default deny. Access is denied by default and explicitly granted as needed. This applies to network rules, application permissions, cloud IAM policies, and repository access.

Policy Scope

Define exactly what the access control policy covers:

• All production systems and environments
• All cloud infrastructure (AWS, Azure, GCP accounts and resources)
• All corporate applications (email, collaboration tools, HR systems)
• All source code repositories
• All databases containing customer or organizational data
• All third-party SaaS tools within the ISMS scope
• All service accounts, API keys, and machine identities
• All employee, contractor, and third-party user accounts

Be explicit about what falls outside scope. If you have development sandbox environments that are intentionally excluded from the ISMS, state that clearly.

User Provisioning and Deprovisioning

The access lifecycle — from granting initial access to revoking it when no longer needed — is where access control either works or fails. Auditors test this rigorously because provisioning and deprovisioning errors are the most common source of excessive access rights.

Provisioning Process

A well-defined provisioning process includes:

1. Access request. All access must be formally requested. The request should specify what access is needed, why, and for how long. For SaaS companies, this typically means a ticket in your project management tool (Jira, Linear, Asana) or a request through your identity management platform.

2. Authorization. The request must be approved by someone with the authority to grant that access — typically the employee’s manager and/or the system owner. Approval must be documented (not a verbal “sure, go ahead”).

3. Implementation. Access is provisioned in accordance with the approved request, using predefined roles wherever possible rather than custom permissions. The person implementing the access should verify that what was provisioned matches what was approved.

4. Verification. After provisioning, verify that the user has the correct access — neither more nor less than what was approved.

5. Documentation. The complete record — request, approval, implementation, and verification — must be retained for audit purposes.

SaaS implementation: Use your identity provider (Okta, Azure AD, Google Workspace) as the central access hub. Define group-based access policies where adding a user to a group automatically provisions the correct access across connected applications. New employee onboarding triggers an automated workflow: HR creates the employee record, the identity provider creates the account, and group memberships provision access based on department and role.

Role-Based Access Control (RBAC)

RBAC is the most practical access management model for SaaS companies. Instead of managing permissions user-by-user, you define roles that map to job functions and assign users to roles.

Define roles based on job functions:

• Engineering — Developer: Read/write access to assigned repositories, read access to staging environments, no production access
• Engineering — Senior Developer: Same as Developer plus read access to production logs and metrics
• Engineering — DevOps/SRE: Same as Senior Developer plus write access to infrastructure-as-code repositories and production deployment capabilities
• Customer Success: Read access to customer data in the support portal, no direct database access
• Finance: Access to billing systems, no access to engineering systems
• Executive: Access to dashboards and reports, no direct system access

RBAC principles for SaaS:

• Keep roles granular enough to enforce least privilege but not so granular that you have a unique role per person
• Document each role’s access rights and review them when job functions evolve
• Use group-based access in your identity provider to implement RBAC technically
• When someone changes roles, revoke the old role’s access and provision the new role’s access — do not accumulate permissions

Deprovisioning Process

Deprovisioning is the highest-risk area of access control. A former employee or contractor with active credentials is a serious security risk and a guaranteed audit finding.

Immediate triggers for deprovisioning:

• Employee termination (voluntary or involuntary)
• Contractor engagement ending
• Third-party relationship terminating
• Employee transferring to a role that does not require the current access

Required deprovisioning timeline: Your policy must specify a maximum time between the trigger event and access removal. For SaaS companies, the standard expectation is:

• Involuntary termination: Access revoked before or at the time the employee is notified, within the same business day
• Voluntary termination: Access revoked by end of the employee’s last working day
• Role changes: Previous role access revoked within 5 business days of the role change effective date
• Contractor completion: Access revoked on the last day of the engagement

SaaS implementation: Integrate your HR system with your identity provider. When HR processes a termination, the identity provider automatically disables the account and revokes all connected application access. For systems not connected to the identity provider (legacy tools, customer-specific environments), maintain a deprovisioning checklist and verify completion.

Critical step often missed: Service accounts, shared credentials, and SSH keys associated with the departing individual. If a former engineer had access to production SSH keys, those keys should be rotated. If they contributed to shared service account credentials, those credentials should be changed. Document this in your deprovisioning procedure.

Access When Changing Roles

Role changes are a significant source of access creep — the gradual accumulation of permissions as employees move between teams without having old permissions revoked. Over time, a person who started in engineering support and moved through QA to product management might retain access from all three roles.

Prevent access creep by:

• Treating internal transfers as a deprovisioning/reprovisioning event
• Comparing the user’s current access against the target role’s defined access rights
• Removing access that is not required for the new role
• Documenting the access change with the same rigor as initial provisioning

Privileged Access Management

Privileged access — administrative accounts with elevated permissions — is the most sensitive access category and receives the most scrutiny during ISO 27001 audits. Control A.8.2 specifically targets privileged access.

What Constitutes Privileged Access in SaaS

• Cloud platform administrators: AWS root account, IAM administrators, Azure Global Administrators, GCP Organization Administrators
• Database administrators: Production database superusers, users with data export capabilities
• Infrastructure management: Kubernetes cluster administrators, network administrators
• Identity provider administrators: Okta super admins, Azure AD Global Admins
• Application administrators: Admin roles in SaaS tools that can view all data or modify security settings
• CI/CD pipeline access: Accounts that can deploy to production, modify pipeline configurations, or access deployment secrets

Privileged Access Controls

Separate privileged and regular accounts. Administrators should have a standard account for daily work (email, Slack, documents) and a separate privileged account for administrative tasks. This reduces the blast radius if the daily-use account is compromised.

Require stronger authentication for privileged access. If MFA is required for standard access, privileged access should require hardware security keys (FIDO2/WebAuthn) rather than SMS or TOTP. Consider requiring re-authentication for sensitive operations even within an authenticated session.

Implement just-in-time (JIT) access. Instead of persistent privileged access, grant temporary elevated permissions when needed for a specific task, with automatic revocation after a defined period.

SaaS implementation: Use tools like AWS IAM Identity Center (formerly SSO) with session duration limits, HashiCorp Vault for dynamic secrets, or dedicated PAM solutions. When an engineer needs production database access for a debugging session, they request JIT access through a workflow that grants temporary credentials for 2-4 hours and logs all activity during that window.

Log all privileged actions. Every action performed with privileged credentials must be logged, and those logs must be protected from modification by the privileged users themselves. Send logs to a centralized SIEM or log management system where they can be reviewed.

Review privileged access quarterly. Privileged access should be reviewed more frequently than standard access. Quarterly reviews are the minimum expectation. During each review, verify that every privileged account is still needed, the access level is still appropriate, and the account owner is still employed and in a role that requires privileged access.

The AWS Root Account Problem

Every AWS account has a root user with unrestricted access. This is a common audit concern.

Best practices:

• Enable MFA on the root account using a hardware security key
• Do not use the root account for day-to-day operations
• Store root account credentials in a secure, physical location (safe or secure vault)
• Log and alert on any root account usage through CloudTrail
• Document the circumstances under which root account access is permitted (typically limited to account-level actions that only root can perform)

Multi-Factor Authentication and Single Sign-On

MFA Requirements

Control A.8.5 requires secure authentication appropriate to the sensitivity of the accessed system. For SaaS companies, this translates to MFA requirements across the environment.

Where MFA should be enforced:

• All identity provider access (non-negotiable)
• All cloud platform console access (AWS, Azure, GCP)
• All production environment access
• All VPN connections
• All code repository access
• All privileged account access
• All administrative access to SaaS tools

MFA strength hierarchy:

1. Hardware security keys (FIDO2/WebAuthn): Most resistant to phishing. Required for privileged access.
2. Authenticator apps (TOTP): Acceptable for standard access. Examples: Google Authenticator, Authy, 1Password.
3. Push notifications: Acceptable but vulnerable to MFA fatigue attacks. Use number-matching if available.
4. SMS codes: Weakest form. Vulnerable to SIM swapping. Avoid for production system access.

Policy recommendation: Require authenticator app MFA as a minimum for all access. Require hardware security keys for privileged access and access to systems containing customer data.

Single Sign-On (SSO)

SSO centralizes authentication through your identity provider and is the most effective way to enforce consistent access control policies across your SaaS tool ecosystem.

Benefits for ISO 27001 compliance:

• Centralized authentication logs for all connected applications
• Consistent MFA enforcement across all systems
• Simplified deprovisioning — disable the IdP account and all connected access is revoked
• Reduced password fatigue and the security risks that come with it

SSO implementation priorities for SaaS companies:

1. First: Cloud platform access (AWS IAM Identity Center, Azure AD, GCP Cloud Identity)
2. Second: Code repositories (GitHub, GitLab, Bitbucket)
3. Third: CI/CD tools (Jenkins, CircleCI, GitHub Actions)
4. Fourth: Communication tools (Slack, Microsoft Teams)
5. Fifth: All remaining SaaS tools that support SSO

The “SSO tax” reality: Many SaaS vendors charge premium pricing for SSO integration. Budget for this during your ISO 27001 implementation planning. The cost of SSO is justified by the compliance benefits and the operational efficiency of centralized access management.

Applications that do not support SSO: Maintain a documented inventory of applications that cannot be connected to SSO. These require individual account management, separate MFA enforcement, and should be prioritized for deprovisioning checklists since they will not be automatically revoked when the IdP account is disabled.

Access Reviews

Control A.5.18 requires that access rights be reviewed at defined intervals. Access reviews are a core audit checkpoint — auditors will request evidence that reviews were completed on schedule and that findings were remediated.

Review Frequency

Quarterly: Privileged access, production environment access, and access to systems containing sensitive customer data. This is the minimum cadence auditors expect for high-risk access.

Semi-annually: Standard application access, code repository access, and corporate tool access.

Annually: Low-risk access, informational systems, and internal documentation platforms.

Your access control policy must specify the review frequency for each category. Do not set a frequency you cannot sustain — a missed review cycle is an audit finding.

How to Conduct Access Reviews

Step 1: Generate access reports. Export current user lists and their permissions from each system under review. Most identity providers can generate consolidated reports across connected applications.

Step 2: Distribute to reviewers. Each system or application should have a designated owner who reviews access for that system. In practice, this often means:

• Engineering leads review production infrastructure access
• Team leads review their team’s application access
• The security team reviews privileged access across all systems

Step 3: Review each entry. For every user-access combination, the reviewer determines:

• Is this person still employed? (Check against HR records)
• Does their current role require this access?
• Is the access level appropriate (not excessive)?
• Is the account active (has it been used recently)?

Step 4: Remediate findings. Remove access that is no longer needed. Downgrade excessive permissions. Disable dormant accounts. Document each remediation action.

Step 5: Document the review. Retain the access report, reviewer comments, remediation actions, and completion date. This is the evidence auditors will request.

SaaS implementation: Build an automated access review workflow. Export user lists from your identity provider and connected systems via API. Present them in a structured format (spreadsheet, GRC platform, or custom tool) where reviewers can approve, flag, or revoke each access entry. Track completion percentage and send reminders to reviewers who have not completed their reviews by the deadline.

Common Access Review Findings

• Orphaned accounts: Accounts belonging to former employees or contractors who were not properly deprovisioned
• Excessive permissions: Users with access beyond what their role requires, often from role changes without access cleanup
• Dormant accounts: Active accounts that have not been used in 60-90+ days, suggesting the access is unnecessary
• Shared accounts: Multiple individuals using the same credentials, violating accountability and audit trail requirements
• Missing MFA: Accounts that should have MFA enforced but do not

SaaS-Specific Access Control Considerations

SaaS companies face access control challenges that do not exist in traditional IT environments. Your policies and procedures must address these explicitly.

Multi-Tenancy

If your product is multi-tenant, access control must ensure strict isolation between tenants. This is both a security requirement and a customer trust issue.

Controls to implement:

• Tenant isolation at the application, database, and network layers
• Access to customer data restricted by tenant context (an engineer debugging one customer’s issue should not be able to access another customer’s data)
• Audit logging of all cross-tenant access
• Regular testing of tenant isolation boundaries (include in penetration testing scope)

API Keys and Service-to-Service Authentication

SaaS products typically expose APIs that customers and partners authenticate against. Managing these credentials is an access control responsibility.

API key management:

• Generate unique API keys per customer or integration, not shared keys
• Support key rotation without service interruption
• Implement key expiration policies
• Log all API key usage and monitor for anomalous patterns
• Provide customers with the ability to revoke and regenerate their own keys
• Never embed API keys in source code or client-side applications

Service-to-service authentication:

• Use short-lived tokens (OAuth 2.0, JWT) rather than long-lived credentials where possible
• Implement mutual TLS (mTLS) for internal service communication in high-security contexts
• Rotate service credentials on a defined schedule
• Store service credentials in a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), not in environment variables or configuration files

CI/CD Pipeline Access

Your deployment pipeline has production access by design — it deploys code, runs migrations, and manages infrastructure. This makes it a high-value target and a critical access control domain.

CI/CD access controls:

• Restrict who can modify pipeline configurations (treat pipeline-as-code with the same controls as application code)
• Use short-lived, scoped credentials for deployment (OIDC federation with AWS, temporary tokens rather than long-lived secrets)
• Require approval gates for production deployments (at minimum, code review; ideally, an explicit deployment approval)
• Log all pipeline executions with full audit trails
• Implement branch protection rules so only the main branch can trigger production deployments
• Separate pipeline credentials by environment (the staging pipeline should not have production credentials)

Customer Data Access for Support

Support engineers and customer success teams may need to access customer data to resolve issues. This access must be controlled, justified, and logged.

Break-glass access model:

• Define clear criteria for when customer data access is permitted (e.g., active support ticket from the customer)
• Require explicit approval for each access event (from a team lead or through an automated workflow)
• Grant time-limited access (automatically revoked after the support session)
• Log all data access during the session
• Anonymize or pseudonymize data in non-production environments so support can troubleshoot without seeing real customer data

Cloud IAM Implementation

For SaaS companies running on major cloud platforms, cloud IAM is the primary mechanism for implementing access control at the infrastructure level.

AWS IAM

Account structure: Use AWS Organizations with separate accounts for production, staging, development, and security/audit. This provides hard account-level boundaries that prevent accidental cross-environment access.

IAM best practices for ISO 27001:

• Never use the root account for operations. Enable MFA and restrict its use.
• Use IAM Identity Center (formerly SSO) to federate access from your identity provider
• Define IAM policies following least privilege — start with no permissions and add only what is needed
• Use IAM roles for applications and services, not IAM users with long-lived access keys
• Enable CloudTrail in all regions for comprehensive audit logging
• Use Service Control Policies (SCPs) to enforce organization-wide guardrails
• Implement permission boundaries to limit the maximum permissions an IAM entity can have

Common AWS audit findings:

• IAM users with inline policies instead of attached managed policies
• Access keys that have not been rotated in 90+ days
• IAM users with console access but no MFA
• Overly permissive policies using wildcards (e.g., "Action": "*", "Resource": "*")
• CloudTrail not enabled in all regions

Azure IAM

Tenant and subscription structure: Use Azure management groups and subscriptions to separate environments. Azure AD (now Entra ID) serves as the identity provider.

Key controls:

• Use Azure AD Privileged Identity Management (PIM) for JIT privileged access
• Implement Conditional Access policies for risk-based authentication
• Enable Azure AD Identity Protection for automated risk detection
• Use managed identities for Azure resources (eliminates credential management for service-to-service access)
• Configure diagnostic settings to stream Azure AD logs to your SIEM

GCP IAM

Resource hierarchy: Use GCP organizations, folders, and projects to separate environments. Cloud Identity or Google Workspace serves as the identity provider.

Key controls:

• Use Workload Identity Federation to avoid service account keys for external workloads
• Implement Organization Policies to enforce constraints across projects
• Use IAM Conditions for context-aware access decisions
• Enable Admin Activity audit logs (always on) and Data Access audit logs for sensitive resources
• Review IAM recommender suggestions for reducing excessive permissions

Logging and Monitoring Access Events

Access control is incomplete without visibility. Controls A.8.15 (Logging) and A.8.16 (Monitoring activities) require that access events be logged and monitored for anomalies.

What to Log

Authentication events:

• Successful and failed login attempts
• MFA challenges and results
• Password changes and resets
• Account lockouts
• SSO token issuance and refresh

Authorization events:

• Access grants and revocations
• Permission changes
• Role assignments and removals
• Privilege escalation events

Administrative events:

• IAM policy changes
• Security group modifications
• Network ACL changes
• Service account creation or modification

Data access events:

• Database queries on sensitive tables
• File access in sensitive storage locations
• API calls that return customer data
• Bulk data exports or downloads

Monitoring and Alerting

Logging is necessary but not sufficient. You must actively monitor logs for suspicious patterns and respond to alerts.

Alert-worthy events:

• Multiple failed login attempts from the same account or IP
• Successful login from an unusual geographic location
• Privileged account usage outside business hours
• Access to sensitive data by accounts that do not typically access it
• Creation of new privileged accounts
• Disabling of MFA on any account
• Access from IP addresses not in your corporate or VPN ranges

SaaS implementation: Forward all access logs to a centralized SIEM (Datadog, Splunk, Elastic, or a cloud-native solution like AWS Security Hub, Azure Sentinel, or GCP Chronicle). Define alerting rules for the events above. Establish a process for triaging and investigating alerts, with escalation to your incident response process for confirmed suspicious activity.

Log Protection

Access logs must be protected from tampering. If a compromised privileged account can modify its own access logs, the logs lose their evidentiary value.

Protection measures:

• Store logs in a separate account or system from the systems being monitored
• Apply write-once, read-many (WORM) or append-only policies to log storage
• Restrict log deletion and modification to a very small number of accounts (or prevent it entirely)
• Monitor for log tampering or deletion as a high-priority alert

Common Audit Findings in Access Control

Understanding what auditors typically find helps you proactively address gaps. These are the most frequent access control findings during ISO 27001 certification audits.

Finding 1: Incomplete Deprovisioning

What auditors test: They request your terminated employee list for the audit period and cross-reference it against user accounts in critical systems.

What they find: Former employees with active accounts in systems not connected to the identity provider — often legacy applications, developer tools, or cloud platform accounts with local credentials.

How to prevent it: Maintain a comprehensive deprovisioning checklist that covers every system in scope. Automate where possible. For systems that cannot be automated, verify deprovisioning completion manually and document the verification.

Finding 2: Excessive Privileged Access

What auditors test: They review the list of users with privileged access and compare it to the organizational chart and role definitions.

What they find: Engineers who were granted admin access for a specific project months ago and still have it. Founders who have root access to everything despite having moved into non-technical roles. Service accounts with admin privileges because it was “easier” to set up.

How to prevent it: Implement quarterly privileged access reviews with documented remediation. Use JIT access for privileged operations so persistent admin access is the exception, not the norm.

Finding 3: Missing or Incomplete Access Reviews

What auditors test: They request evidence of completed access reviews for the audit period, matching the frequency stated in your access control policy.

What they find: Reviews that were supposed to happen quarterly but only happened twice. Reviews that were conducted but lacked documentation of findings and remediation. Reviews that covered some systems but not all systems in scope.

How to prevent it: Automate access review scheduling. Set calendar reminders with enough lead time to complete the review before the deadline. Use a structured review template that captures the date, reviewer, systems reviewed, findings, and remediation actions. See our ISO 27001 certification checklist for a complete timeline of recurring activities.

Finding 4: Shared Accounts

What auditors test: They look for accounts used by multiple individuals, which violates accountability and audit trail requirements.

What they find: Shared “admin” accounts for SaaS tools that do not support SSO. Shared credentials for legacy systems. Generic “deploy” accounts used by multiple engineers.

How to prevent it: Eliminate shared accounts wherever possible. Where shared accounts are technically unavoidable (some legacy systems), implement compensating controls: check-in/check-out procedures, session recording, and usage logging that identifies who used the shared account at any given time.

Finding 5: Insufficient MFA Coverage

What auditors test: They verify that MFA is enforced on all systems where your policy requires it.

What they find: MFA policies configured in the identity provider but with exceptions for certain users or applications. Cloud platform accounts with MFA enabled on the console but not for CLI access. Applications that support MFA but where it was never enabled.

How to prevent it: Audit MFA enforcement across all systems in scope. Close exception gaps. For systems that do not support MFA, document the limitation and implement compensating controls (IP restrictions, VPN requirements, enhanced logging).

Frequently Asked Questions

What is the difference between access control in ISO 27001 and SOC 2?

The underlying requirements are nearly identical — both frameworks expect least privilege, MFA, access reviews, provisioning/deprovisioning controls, and privileged access management. The difference is in the framework structure. ISO 27001 organizes access control requirements across specific Annex A controls. SOC 2 addresses access control through Common Criteria (primarily CC6.1 through CC6.8). A SaaS company implementing access controls for one framework will satisfy most of the other framework’s requirements with minimal additional effort.

How often must access reviews be conducted?

ISO 27001 does not prescribe a specific frequency — it requires reviews “at planned intervals.” You define the frequency in your access control policy. The industry standard for certification audits is quarterly reviews for privileged and sensitive access, and semi-annual or annual reviews for standard access. Whatever frequency you define, you must demonstrate consistent execution.

Do we need a separate privileged access management (PAM) tool?

Not necessarily. The requirement is to control privileged access — how you implement that control is up to you. Small SaaS companies can manage privileged access through IAM policies, JIT access scripts, and documented manual processes. As you scale, a dedicated PAM tool (CyberArk, BeyondTrust, HashiCorp Vault) becomes increasingly valuable for centralizing privileged credential management, implementing session recording, and automating credential rotation.

How should we handle access control for customer data in a multi-tenant SaaS product?

Tenant isolation must be enforced at the technical level — application logic, database queries (row-level security or schema/database-per-tenant), and network segmentation. Internal access to customer data should require explicit justification (active support ticket), time-limited access grants, and comprehensive logging. Consider implementing a customer data access policy that separates this from your general access control policy due to its sensitivity and the additional controls required.

What is the relationship between our access control policy and our risk assessment?

Your risk assessment identifies risks related to unauthorized access, excessive privileges, and access control failures. The access control policy defines the controls that treat those risks. The two should be explicitly linked — each access control requirement in your policy should trace to a risk it addresses, and each access-related risk in your risk register should trace to the control that mitigates it. This traceability is something auditors look for and is documented in your Statement of Applicability.

How GRCTrail Helps

GRCTrail simplifies ISO 27001 access control implementation and ongoing compliance for SaaS companies:

• Automated access reviews that pull user lists from your identity provider and connected systems, route them to the appropriate reviewers, track completion, and retain evidence — eliminating the spreadsheet-based review process that causes missed deadlines
• Access control policy templates tailored for SaaS companies, covering every relevant Annex A control with practical language for cloud environments, CI/CD pipelines, and multi-tenant architectures
• Continuous monitoring dashboards that track MFA enforcement, dormant accounts, and privileged access across your environment, alerting you to drift before your auditor finds it

Get started with GRCTrail

Related Guides

• What Is ISO 27001? A Practical Guide for SaaS Companies
• ISO 27001 Annex A Controls: The Complete Guide
• ISO 27001 Policies: Which Policies You Need and How to Write Them
• ISO 27001 Certification Checklist
• ISO 27001 Risk Assessment Guide