Access Control

1. Discretionary (DAC)

   • Based on the resource owner’s discretion.
   • Owners determine who has access to their resources and define permissions.
   • Commonly used in file systems.

2. Mandatory (MAC)

   • Enforced by a central authority, often using classification levels.
   • Users and data are assigned security labels, and access is granted based on policies.

3. Role-Based (RBAC)

   • Access is assigned based on roles within an organization.
   • A user can only perform actions permitted for their role (e.g., HR, IT admin).

4. Attribute-Based (ABAC)

   • Uses attributes (e.g., time of access, location, device type) to grant or deny access.
   • Offers granular and dynamic control.

5. Rule-Based

   • Based on pre-set rules (e.g., allow access from 9 AM to 5 PM).
   • Often used in combination with other models.

Access control vs. identity and access management

Identity and access management, or IAM, is the broader system used to create and manage digital identities, authentication methods, access rights and identity lifecycles.

Access control is a major part of IAM, but the terms are not identical.

IAM typically handles:

• Identity creation
• Single sign-on
• Authentication
• Multi-factor authentication
• User provisioning
• Group and role assignment
• Password management
• Account deactivation

Access control governance addresses:

• Access policies
• Approval requirements
• Role design
• Least privilege
• Segregation of duties
• Periodic access reviews
• Exception management
• Control testing
• Evidence retention
• Audit reporting
• Corrective actions

An IAM platform may enforce permissions, while a GRC or compliance platform helps govern the policies, controls, reviews and evidence surrounding those permissions.

How does access control work?

A mature access control process follows a defined lifecycle rather than treating access as a one-time technical configuration.

1. Identify the user or system

The organization establishes a unique identity for the employee, contractor, vendor, device, application or service account.

Shared accounts should be limited because they make it difficult to determine which individual performed an action.

2. Authenticate the identity

The system verifies that the requester is who they claim to be. Authentication may involve:

• Passwords
• Security keys
• Biometrics
• One-time codes
• Certificates
• Tokens
• Multi-factor authentication

Authentication strength should reflect the sensitivity of the system and the consequences of unauthorized access.

3. Evaluate the access request

The organization determines what access the requester needs based on factors such as:

• Job role
• Department
• Employment status
• Data sensitivity
• Location
• Device security
• Time of access
• Business purpose
• Risk level
• Contract terms

4. Obtain approval

The appropriate system owner, manager, data owner or security representative reviews and approves the request.

High-risk access may require more than one approval. For example, privileged administrator access could require approval from both the user’s manager and the system owner.

5. Provision the approved permissions

The approved access is configured in the target system. The assigned permissions should match the request and approval record.

6. Monitor access activity

Organizations should log access events, permission changes, failed attempts, privileged actions and unusual behavior where appropriate.

Centralized logging is one of the security practices recommended by CISA, together with controlling access and strengthening credenti

7. Review access periodically

Managers and system owners should verify that users still require their assigned permissions.

Access reviews may be performed monthly, quarterly, semiannually or annually depending on the system’s risk and applicable requirements.

8. Modify or revoke access

Access should be changed promptly when:

• An employee changes roles
• A contractor’s assignment ends
• A vendor relationship changes
• An account becomes inactive
• A user no longer requires a privilege
• A policy violation occurs
• Employment is terminated

Delayed revocation can leave dormant or inappropriate access available long after the business need has ended.

Three categories of access control

Access controls can be grouped into physical, logical and administrative controls.

Physical access control

Physical access control restricts entry to buildings, rooms, equipment and secured areas.

Examples include:

• Access cards
• Biometric scanners
• Security guards
• Door locks
• Visitor badges
• Turnstiles
• Video surveillance
• Secured cabinets
• Data center entry controls

Physical access should also follow least privilege. Employees should receive entry only to the facilities and restricted areas required for their work.

Logical access control

Logical access control restricts digital access to systems, networks, applications, files and data.

Examples include:

• Usernames and passwords
• Multi-factor authentication
• Application permissions
• Network access rules
• Database permissions
• Cloud IAM policies
• File permissions
• API authorization
• Privileged access controls
• Session restrictions

Logical access control commonly relies on roles, attributes, rules or resource-specific permissions.

Administrative access control

Administrative controls establish how access is governed.

Examples include:

• Access control policies
• Joiner, mover and leaver procedures
• Access request forms
• Approval workflows
• User access reviews
• Segregation-of-duties rules
• Privileged access standards
• Vendor access procedures
• Exception approvals
• Access retention requirements

Technical controls are unlikely to remain effective without administrative processes that establish ownership and accountability.

What are the main access control models?

An access control model defines how permissions are assigned and how access decisions are made.

The main access control models are discretionary access control, mandatory access control, role-based access control and attribute-based access control. Organizations may combine models depending on their systems and security requirements.

1. Discretionary access control

Under discretionary access control, or DAC, the owner of a resource decides who may access it and what permissions they receive.

A file owner, for example, may permit another employee to view or edit a document.

Advantages of DAC

• Flexible
• Familiar to users
• Suitable for collaboration
• Easy to apply to individual resources

Limitations of DAC

• Permissions may spread without central oversight
• Resource owners may assign excessive access
• Permission structures can become inconsistent
• Large-scale reviews may be difficult

DAC is common in shared file systems but may require additional monitoring for sensitive information.

2. Mandatory access control

Mandatory access control, or MAC, applies centrally established security classifications and rules. Individual users cannot change the access policy at their discretion.

A system may classify information as confidential, secret or top secret and permit access only to users with the required clearance.

Advantages of MAC

• Strong centralized enforcement
• Consistent handling of classified resources
• Suitable for high-security environments

Limitations of MAC

• Less flexible for changing business needs
• Requires careful classification
• Can be difficult to administer

MAC is often associated with government, military and other high-security environments.

3. Role-based access control

Role-based access control, or RBAC, assigns permissions to defined job roles rather than directly to each user.

Users receive one or more roles, and each role contains approved permissions.

For example:

• An accounts-payable clerk can create invoices.
• A finance manager can approve invoices.
• A payroll administrator can update payroll records.
• A compliance reviewer can view evidence and record review results.

NIST describes RBAC as a proven approach for large-scale authorization. Its model connects users, roles, permissions and role relationsh

Advantages of RBAC

• Easier to manage at scale
• Supports consistent access assignment
• Aligns permissions with business functions
• Simplifies onboarding and role changes
• Supports segregation of duties

Limitations of RBAC

• Poorly designed roles can create excessive access
• Too many specialized roles can cause role explosion
• Roles require periodic review
• Static roles may not address contextual risk

RBAC is one of the most widely used access control models for business applications.

4. Attribute-based access control

Attribute-based access control, or ABAC, evaluates attributes associated with the user, resource, requested action and environment.

Attributes may include:

• Department
• Job title
• Employment type
• Security clearance
• Resource classification
• Device status
• Geographic location
• Time of day
• Network
• Risk score

NIST defines ABAC as an approach in which access decisions are based on attributes of subjects and objects and the policy-defined relationship between those attribu

For example, a policy could permit a clinician to access a patient record only when the clinician is assigned to the patient, is using a managed device and is connected from an approved location.

Advantages of ABAC

• Supports detailed access decisions
• Adapts to context
• Suitable for complex environments
• Can address dynamic access requirements

Limitations of ABAC

• Policies may become difficult to understand
• Attribute quality must be maintained
• Testing can be more complex
• Conflicting rules may produce unexpected results

5. Rule-based access control

Rule-based access control uses system-wide rules to permit or deny access.

Examples include:

• Deny access outside business hours
• Require MFA for external access
• Block access from unmanaged devices
• Permit database access only from an approved network
• Terminate inactive sessions after a set period

Rule-based controls are often combined with RBAC or ABAC.

6. Relationship-based access control

Relationship-based access control, or ReBAC, grants access according to the relationship between the requester and the resource.

Examples include:

• A user can edit a project if they are a project member.
• A manager can view records for their direct reports.
• A physician can access records for assigned patients.
• A customer can view accounts they own.

ReBAC is useful for applications in which relationships change frequently and cannot be represented adequately by static roles.

Access control model comparison

Model	Access is based on	Best suited for	Primary challenge
DAC	Resource owner decisions	File sharing and collaboration	Inconsistent permissions
MAC	Central classifications	High-security environments	Limited flexibility
RBAC	Job roles	Enterprise applications	Role design and role explosion
ABAC	User, resource and environmental attributes	Complex and dynamic systems	Policy complexity
Rule-based	Predefined system rules	Network and contextual restrictions	Rule conflicts
ReBAC	Relationships between entities	Collaborative and data-sharing applications	Relationship governance

Most organizations use more than one model. An application might use RBAC for standard permissions, ABAC for contextual restrictions and rules for session or device security.

Core principles of effective access control

Principle of least privilege

Least privilege means users receive only the minimum access required to perform approved responsibilities.

A user should not receive administrator access simply because it is convenient. Access should be limited by system, function, data, time and business purpose where practical.

Need to know

Need-to-know access limits sensitive information to individuals who require it for an authorized task.

An employee may have the technical ability to use a system but still lack a valid business need to access a particular dataset.

Deny by default

Under deny by default, access is denied unless an approved policy explicitly permits it.

This reduces the risk of accidentally exposing a new system, function or dataset.

Segregation of duties

Segregation of duties prevents one person from controlling conflicting stages of a critical process.

Examples include separating:

• Invoice creation from payment approval
• Code development from production deployment
• Access requests from access approval
• Evidence submission from control testing
• Vendor creation from vendor payment

Segregation of duties reduces fraud, error and unauthorized activity.

Just-in-time access

Just-in-time access grants elevated permissions only when required and removes them after a defined period.

This is particularly valuable for privileged access, emergency access and temporary vendor support.

Periodic recertification

Permissions should be reviewed at defined intervals. Managers and resource owners should confirm whether access is still appropriate and document the review decision.

Prompt deprovisioning

Access should be removed promptly when a user leaves the organization or no longer requires a resource.

Individual accountability

Users should have unique identities wherever possible. Shared accounts weaken traceability and make investigations more difficult.

What is an access control policy?

An access control policy defines the organization’s rules for granting, using, reviewing, changing and revoking access to information, systems and physical locations.

The policy establishes the governance expectations that IAM systems, administrators, managers and users must follow.

A strong access control policy should address:

• Purpose and scope
• Roles and responsibilities
• Identity requirements
• Authentication requirements
• Access request procedures
• Approval authorities
• Least-privilege expectations
• Role-based access
• Privileged access
• Segregation of duties
• Remote access
• Vendor and contractor access
• Physical access
• Emergency access
• Access review frequency
• Account inactivity
• Termination and offboarding
• Monitoring and logging
• Exceptions
• Violations
• Evidence retention
• Policy review and approval

The policy should reflect actual operating processes. A policy that describes controls the organization does not perform may create additional audit risk.

Access control and regulatory compliance

Access control is included in many security and compliance requirements because it protects the confidentiality, integrity and availability of sensitive information.

NIST SP 800-53

NIST SP 800-53 provides a catalog of security and privacy controls, including an Access Control family. The controls address areas such as account management, access enforcement, information flow, separation of duties, least privilege, remote access and wireless acc

HIPAA

The HIPAA Security Rule requires regulated organizations to apply administrative, physical and technical safeguards to protect electronic protected health information. Its technical safeguards include an access control standard intended to allow access only to individuals or software programs that have been granted access rig

PCI DSS

PCI DSS establishes technical and operational requirements for protecting payment account data. Organizations that store, process or transmit cardholder data must restrict access according to business need, identify users and authenticate access to system components. The currently published limited revision is PCI DSS v4.

NERC CIP

NERC Critical Infrastructure Protection standards address the cybersecurity of applicable Bulk Electric System environments. CIP standards cover areas including personnel access, electronic security perimeters and physical security. NERC states that CIP-005 is intended to manage electronic access to BES Cyber Systems through controlled Electronic Security Perimet

ISO/IEC 27001

Access control is a central information-security practice for managing movement through physical facilities and access to networks, systems and information. Organizations using an information security management system should connect access requirements to their risk assessment, security policies and operating contr

Access control audit evidence

Implementing access controls is only part of compliance. Organizations must also retain evidence showing that those controls operated as intended.

Common access control evidence includes:

• Approved access requests
• User and role listings
• Permission reports
• Manager approvals
• System-owner approvals
• Access review records
• Privileged account inventories
• Authentication configuration reports
• MFA enrollment reports
• Termination checklists
• Account deactivation records
• Role-change tickets
• Segregation-of-duties reviews
• Exception approvals
• Vendor access records
• Physical entry logs
• Monitoring logs
• Corrective action records
• Policy versions and approvals
• Employee policy attestations

Evidence should identify the applicable control, reviewer, review date, population examined, exceptions found and remediation status.

Common access control failures

Excessive permissions

Users accumulate access as they change roles but retain permissions from previous responsibilities. This is commonly called privilege creep.

Orphaned accounts

Accounts remain active after employees, contractors or vendors leave.

Weak role design

Roles contain broad or conflicting permissions because they were not designed around actual responsibilities.

Uncontrolled privileged access

Administrator access is assigned permanently, shared or insufficiently monitored.

Incomplete access reviews

Managers approve large access lists without verifying individual permissions or business need.

Weak evidence

The organization performs access reviews but does not retain the reviewed population, reviewer decision, exceptions or remediation evidence.

Shared accounts

Multiple users operate under the same credentials, reducing accountability.

Inconsistent offboarding

Access is removed from primary systems but remains active in cloud services, local applications, physical facilities or vendor portals.

Unmanaged third-party access

Vendor access lacks an owner, expiration date, periodic review or clear business justification.

Policy and practice misalignment

The access control policy requires quarterly reviews, but the organization reviews access annually or cannot demonstrate that the review occurred.

Access control best practices

1. Create a complete system and data inventory

Identify applications, databases, devices, cloud environments, physical locations and sensitive datasets requiring access restrictions.

2. Assign resource owners

Every important system and dataset should have an accountable business or technical owner.

3. Define access requirements

Document who should receive access, why they need it, what permissions are appropriate and who must approve the request.

4. Apply least privilege

Start with the minimum permissions required and add access only when there is a documented need.

5. Use role-based access where appropriate

Create roles that reflect stable business responsibilities. Avoid assigning permissions individually unless there is a clear reason.

6. Strengthen privileged access

Require stronger authentication, limited duration, additional approval and activity monitoring for administrator and other elevated accounts.

7. Automate joiner, mover and leaver processes

Connect HR, IT, security and system owners so that onboarding, role changes and offboarding trigger the appropriate access actions.

8. Review access based on risk

Review high-risk systems and privileged permissions more frequently than low-risk systems.

9. Track exceptions

Document why an exception is required, who approved it, what compensating control applies and when the exception expires.

10. Test access controls

Do not rely only on policies and system configuration. Test whether inappropriate access is prevented, detected and corrected.

11. Retain audit-ready evidence

Store access requests, approvals, reviews, exceptions and remediation records in a controlled repository.

12. Measure the program

Useful access control metrics include:

• Percentage of accounts reviewed on time
• Number of inactive accounts
• Number of orphaned accounts
• Percentage of privileged accounts with MFA
• Average time to revoke terminated-user access
• Number of unresolved access-review exceptions
• Number of segregation-of-duties conflicts
• Percentage of vendor accounts with expiration dates

How to conduct a user access review

A user access review verifies that each user has appropriate permissions for their current responsibilities.

Step 1: Define the review scope

Select the systems, roles, groups, permissions, privileged accounts and review period.

Step 2: Obtain a complete population

Extract the full user and permission listing directly from the system where possible.

Step 3: Assign reviewers

Select managers, system owners, data owners or control owners with sufficient knowledge to make the decision.

Step 4: Provide decision criteria

Reviewers should know how to identify:

• Terminated users
• Inactive accounts
• Former employees
• Excessive permissions
• Conflicting permissions
• Unapproved privileged access
• Vendor accounts without current need
• Access inconsistent with job responsibilities

Step 5: Document decisions

Record whether each permission should be retained, modified or revoked.

Step 6: Remediate exceptions

Assign identified changes to a responsible owner and establish a due date.

Step 7: Verify completion

Confirm that approved changes were made in the target system.

Step 8: Retain evidence

Keep the source population, reviewer decisions, approvals, remediation records and final sign-off.

How access control software supports compliance

Access control enforcement generally occurs through IAM, directory, application, network and privileged-access technologies.

A compliance or GRC platform serves a different purpose. It helps organizations govern the access control program by connecting policies, controls, tasks, evidence, risks and corrective actions.

A GRC platform can help teams:

• Maintain access control policies
• Assign policy owners
• Manage review and approval workflows
• Distribute policies and collect attestations
• Map access controls to regulations and frameworks
• Schedule user access reviews
• Assign review owners
• Collect access-review evidence
• Track exceptions and remediation
• Monitor overdue activities
• Maintain audit trails
• Report access-control status to leadership

The platform should complement, rather than replace, the technical systems that enforce identity and permissions.

How VComply helps govern access controls

VComply helps compliance, security, IT and business teams manage the governance work surrounding access control.

Organizations can use VComply to:

• Maintain and approve access control policies
• Connect access requirements to internal controls
• Assign owners and recurring review tasks
• Track access-review completion
• Collect supporting evidence
• Record control exceptions
• Assign corrective actions
• Monitor overdue remediation
• Maintain policy version history
• Collect employee attestations
• Prepare evidence for audits and assessments
• Report control status through dashboards

For example, an organization can schedule quarterly privileged-access reviews, assign each application to its system owner, request the applicable user listing, record reviewer decisions and track identified removals to closure.

VComply does not replace IAM, SSO, MFA or privileged-access management technology. It provides the policy, control, evidence and accountability layer needed to show that access controls are governed and reviewed consistently.