Access Control: What It Is, Models, Best Practices, and Compliance Requirements
A practical guide to access control — what it is, access control models (RBAC, ABAC, MAC, DAC), the principle of least privilege, how access control maps to ISO 27001, SOC 2, NIS2, and DORA requirements, and how B2B companies can implement effective access management.
Access Control: What It Is, Models, Best Practices, and Compliance Requirements
Access control is the practice of restricting access to systems, data, and resources to authorised users based on defined policies. It is a foundational security control that underpins every compliance framework, from ISO 27001 and SOC 2 to NIS2 and DORA.
For B2B companies, access control is one of the first areas enterprise buyers scrutinise. Security questionnaires routinely ask about access management policies, authentication mechanisms, privileged access controls, and access review processes. Demonstrating mature access control practices builds trust and accelerates deal cycles.
This guide covers access control models, the principle of least privilege, privileged access management, compliance mapping, and how to implement effective access control.
Access Control Models
Choosing the Right Model
| Model | How It Works | Best For | Complexity |
|---|---|---|---|
| RBAC (Role-Based) | Permissions assigned to roles; users assigned to roles | Most enterprise environments | Medium |
| ABAC (Attribute-Based) | Access decisions based on user, resource, action, and environment attributes | Complex environments needing fine-grained control | High |
| MAC (Mandatory) | Access enforced by security classifications and clearance levels | Government, military, classified environments | High |
| DAC (Discretionary) | Resource owners control access at their discretion | File systems, small teams | Low |
| PBAC (Policy-Based) | Centralised policies govern access across systems | Large-scale environments with diverse access needs | High |
RBAC in Practice
RBAC is the most widely adopted model for B2B companies. Permissions are assigned to roles, and users are assigned to one or more roles based on their job function.
| Component | Description | Example |
|---|---|---|
| Role | A named collection of permissions aligned to a job function | "Finance Manager", "Developer", "Security Analyst" |
| Permission | An allowed action on a specific resource | "Read financial reports", "Deploy to staging" |
| User-role assignment | Mapping users to their organisational roles | Jane Smith → Finance Manager |
| Role hierarchy | Roles can inherit permissions from parent roles | "Senior Developer" inherits "Developer" permissions |
| Constraints | Rules that restrict role combinations | Cannot hold both "Payment Approver" and "Payment Initiator" |
The Principle of Least Privilege
Core Concepts
The principle of least privilege (PoLP) requires that every user, application, and system has only the minimum access needed to perform its function.
| Principle | Implementation |
|---|---|
| Default deny | Start with no access; grant permissions explicitly |
| Need-to-know | Access to data only when required for the specific task |
| Time-limited access | Elevated privileges expire after a defined period |
| Scope limitation | Access restricted to specific resources, not broad categories |
| Regular review | Permissions reviewed and pruned on a regular cycle |
Privilege Creep
Privilege creep occurs when users accumulate access rights over time — through role changes, project assignments, or ad-hoc requests — without corresponding revocations. Left unchecked, it leads to:
- Users with far more access than their current role requires
- Increased attack surface if an account is compromised
- Audit findings for excessive or inappropriate access
- Violations of segregation of duties
Prevention: Conduct quarterly access reviews, implement automated access recertification, and enforce access expiry for temporary permissions.
Privileged Access Management (PAM)
Why PAM Matters
Privileged accounts (administrators, root, service accounts) have elevated access that can affect entire systems. Compromising a privileged account gives an attacker broad access to infrastructure, data, and configurations.
| PAM Control | Purpose |
|---|---|
| Credential vaulting | Store privileged credentials in a secure vault with automated rotation |
| Just-in-time (JIT) access | Grant elevated privileges temporarily; revoke after use |
| Session recording | Record and monitor all privileged sessions for audit |
| Break-glass procedures | Emergency access with full audit trail and post-incident review |
| Separation of duties | No single person has unchecked privileged access |
| Service account management | Inventory, rotate, and monitor non-human privileged accounts |
Authentication Mechanisms
Multi-Factor Authentication (MFA)
| Factor Type | Examples | Strength |
|---|---|---|
| Something you know | Password, PIN, security questions | Low (can be phished or guessed) |
| Something you have | Hardware security key (FIDO2/WebAuthn), authenticator app, smart card | High (physical possession required) |
| Something you are | Fingerprint, facial recognition, iris scan | High (biometric) |
Best practice: Require MFA for all users, with phishing-resistant methods (hardware keys, passkeys) for privileged accounts and critical systems.
Authentication Best Practices
| Practice | Description |
|---|---|
| Enforce MFA | Require multi-factor authentication for all users |
| Use phishing-resistant MFA | Hardware keys or passkeys for privileged access |
| Eliminate shared accounts | Every user has a unique, identifiable account |
| Implement SSO | Single Sign-On reduces password fatigue and centralises authentication |
| Password policies | Minimum length, complexity, and prohibition of known-compromised passwords |
| Session management | Automatic timeout, re-authentication for sensitive actions |
Access Control and Compliance
Regulatory Mapping
| Requirement | Framework | Access Control Alignment |
|---|---|---|
| Access control policy | ISO 27001 A.5.15, SOC 2 CC6.1 | Documented access control rules and principles |
| Identity management | ISO 27001 A.5.16 | User lifecycle management (joiners, movers, leavers) |
| Authentication | ISO 27001 A.5.17, A.8.5, SOC 2 CC6.1 | MFA, secure credential management |
| Access provisioning | ISO 27001 A.5.18, SOC 2 CC6.2 | Role-based provisioning with approval workflows |
| Privileged access | ISO 27001 A.8.2, SOC 2 CC6.1 | PAM controls, monitoring, and audit |
| Access reviews | ISO 27001 A.5.18, SOC 2 CC6.2, CC6.3 | Regular recertification of user access |
| Network security | NIS2 Art. 21(2)(b), DORA Art. 9 | Network access controls and segmentation |
| ICT security | DORA Art. 9(4) | Strong authentication, access rights management |
SOC 2 Trust Services Criteria — Access Control
| Criterion | Focus |
|---|---|
| CC6.1 | Logical and physical access controls, authentication mechanisms |
| CC6.2 | Registration and authorisation of new users, provisioning access |
| CC6.3 | Removal of access when no longer needed (termination, role change) |
| CC6.4 | Restriction and monitoring of physical access |
| CC6.5 | Protection against external threats (network controls, firewalls) |
| CC6.6 | Encryption and protection of data in transit and at rest |
User Access Lifecycle
Joiners, Movers, Leavers (JML)
| Phase | Actions | Timeframe |
|---|---|---|
| Joiner | Create accounts, assign roles based on job function, grant minimum required access, provide security training | Before or on start date |
| Mover | Review current access, revoke access no longer needed, grant access for new role, update role assignments | Within 24 hours of role change |
| Leaver | Disable accounts immediately, revoke all access, recover company devices and credentials, archive data | On or before last day |
Common Access Control Weaknesses
| Weakness | Risk | Mitigation |
|---|---|---|
| No formal JML process | Orphaned accounts, excessive access | Document and automate JML procedures |
| Missing access reviews | Privilege creep, audit findings | Schedule quarterly automated reviews |
| Shared accounts | No accountability, audit gaps | Mandate individual accounts for all users |
| No MFA | Credential theft, account takeover | Enforce MFA across all systems |
| Over-provisioned roles | Excessive access, blast radius | Apply least privilege, right-size roles |
| No PAM controls | Unmonitored admin access | Implement credential vaulting and session recording |
How Orbiq Supports Access Control
- Trust Center: Publish your access control posture — policies, MFA enforcement, and review processes for buyer self-service
- Continuous Monitoring: Track access control compliance across ISO 27001, SOC 2, NIS2, and DORA
- AI-Powered Questionnaires: Auto-respond to access control questions from enterprise buyers using your documented controls
- Evidence Management: Centralise access review records, JML documentation, and PAM evidence for auditors
Further Reading
- Zero Trust Architecture — Access control in a zero trust model
- Security Audit — How auditors evaluate access control
- ISO 27001 Certification — ISO 27001 access control requirements
- SOC 2 Compliance — SOC 2 logical access criteria
- Penetration Testing — Testing access control effectiveness
This guide is maintained by the Orbiq team. Last updated: March 2026.