Access Management Procedure

1. Purpose

The Access Management Procedure defines how user, privileged, service, application, cloud, database, and third-party access is requested, approved, provisioned, reviewed, modified, and revoked.

The objective is to ensure that:

Access is based on legitimate business need.
Users receive only the access required for their role.
Access is appropriately authorized.
Authentication controls are applied.
Privileged access is tightly controlled.
Access is reviewed periodically.
Access is removed when no longer required.
Access activities are traceable and auditable.

Core Principle

Request → Verify → Approve → Provision → Authenticate → Monitor → Review → Revoke

2. Scope

This procedure applies to access to:

Corporate applications
Cloud environments
Servers
Databases
SaaS applications
Network infrastructure
Production systems
Development and test environments
Source-code repositories
CI/CD systems
Security systems
File storage
Business applications
Customer environments where applicable
Third-party systems
Physical systems where access is managed electronically

It applies to:

Employees
Contractors
Interns
Consultants
Temporary personnel
Suppliers
Service providers
Administrators
Other authorized users

3. Access Management Information

Field	Details
Procedure ID
Procedure Owner
Access Management Owner
Security Owner
Version
Effective Date
Review Date
Classification
Status	Draft / Approved / Retired
Approved By

4. Access Management Objectives

Access management should ensure:

☐ Business need is established
☐ User identity is verified
☐ Access is authorized
☐ Least privilege is applied
☐ Segregation of duties is considered
☐ MFA is implemented where required
☐ Privileged access is restricted
☐ Temporary access is controlled
☐ Access is monitored where appropriate
☐ Access is periodically reviewed
☐ Excess access is removed
☐ Departing users lose access promptly
☐ Evidence is retained

5. Access Types

Identify the applicable access category.

☐ Standard user access
☐ Privileged access
☐ Administrator access
☐ Production access
☐ Database access
☐ Cloud access
☐ Source-code access
☐ CI/CD access
☐ Remote access
☐ VPN access
☐ SaaS application access
☐ Service account
☐ API access
☐ Machine-to-machine access
☐ Temporary access
☐ Emergency access
☐ Supplier/third-party access

6. Roles and Responsibilities

Role	Responsibility
User	Requests and uses access appropriately
Manager	Confirms business need
System Owner	Approves system access
Access Administrator	Provisions/revokes access
Security Team	Defines and monitors security requirements
HR	Provides joiner/mover/leaver information
Application Owner	Approves application-specific access
Cloud Administrator	Manages cloud access
Database Owner	Approves database access
Supplier Owner	Manages third-party access
Risk Owner	Accepts significant access-related risk
Management	Provides oversight

7. Access Request

Access must be requested through an approved process.

A request should include:

User identity
Department/team
Role
System/application
Requested permissions
Business justification
Access duration
Environment
Manager
System owner
Required start date
Expiry date where applicable

Access Request

Field	Details
User
System
Role
Permission
Business Need
Start Date
Expiry Date
Manager Approval
System Owner Approval

8. Identity Verification

Before granting access, verify that:

☐ User identity is known
☐ Employment/engagement status is valid
☐ User belongs to the relevant organization
☐ Request originates through an approved channel
☐ Required approvals are authentic
☐ Access is being provided to the correct account

Shared or anonymous accounts should not be used unless specifically justified and controlled.

9. Business Need

Every significant access right should have a legitimate business purpose.

Examples:

Employee role
Customer support
Software development
Cloud administration
Security monitoring
Finance operations
HR administration
Supplier support

Business Justification

10. Least Privilege

Access must be limited to the minimum permissions required.

Consider:

Read vs. write
User vs. administrator
Development vs. production
Application vs. infrastructure
Individual vs. group access
Temporary vs. permanent access

Principle

Minimum Access + Minimum Privilege + Minimum Duration

11. Role-Based Access

Where practical, use predefined roles.

Examples:

Role	Typical Access
Developer	Development environment
Support	Approved support systems
Finance	Finance applications
HR	HR systems
Cloud Administrator	Approved cloud administration
Security Administrator	Security tools
Auditor	Read-only evidence access

Role definitions should be periodically reviewed.

12. Joiner Access

For new personnel:

HR/authorized owner confirms onboarding.
Manager identifies required systems.
Access requests are submitted.
Required approvals are obtained.
Accounts are created.
MFA is configured.
Access is validated.
Access records are retained.

Access should reflect the individual’s actual role.

13. Mover Access

When personnel change roles:

Identify the role change.
Review existing access.
Identify newly required access.
Remove access no longer required.
Obtain required approvals.
Grant new access.
Verify the resulting access.
Record the change.

A role change should not simply result in additional permissions being added indefinitely.

14. Leaver Access

When employment or engagement ends:

Receive authorized termination notification.
Identify all accounts and access.
Disable or revoke access.
Remove privileged access.
Revoke VPN/remote access.
Revoke cloud access.
Revoke SaaS access.
Disable source-code access.
Address API keys/tokens/service credentials where applicable.
Recover organizational assets.
Record completion.

For high-risk or involuntary termination, access revocation should be coordinated with HR, management, and security as appropriate.

15. Access Provisioning

Access administrators should:

☐ Use approved account
☐ Assign approved permissions
☐ Apply least privilege
☐ Configure MFA
☐ Avoid shared credentials
☐ Apply expiry where required
☐ Record provisioning
☐ Verify access

Access must not be granted solely on an informal request when formal approval is required.

16. Authentication

Access must use appropriate authentication mechanisms.

Consider:

☐ Unique user ID
☐ Password controls
☐ MFA
☐ SSO
☐ Strong authentication
☐ Device authentication
☐ Certificate-based authentication
☐ Conditional access
☐ Privileged authentication controls

Authentication requirements should be proportionate to system and information risk.

17. Multi-Factor Authentication

MFA should be enabled for systems where required by risk, policy, contractual, or regulatory requirements.

MFA should be prioritized for:

Administrator accounts
Cloud accounts
Production systems
Security tools
Remote access
Source-code repositories
Critical SaaS applications
Systems containing sensitive information

18. Privileged Access

Privileged access requires enhanced controls.

☐ Named administrator account
☐ Business justification
☐ Approval
☐ MFA
☐ Least privilege
☐ Separate administrative account where appropriate
☐ Logging
☐ Monitoring
☐ Periodic review
☐ Expiry where practical
☐ Immediate revocation when no longer required

19. Administrator Accounts

Where practical, administrative activity should be performed using dedicated administrative accounts.

Avoid using administrator privileges for ordinary activities such as:

Email
Web browsing
General document editing
Personal activity

20. AWS Cloud Access

For AWS environments:

☐ IAM users/roles identified
☐ IAM roles used where appropriate
☐ MFA enabled
☐ Root account protected
☐ Root access restricted
☐ Least privilege applied
☐ Administrative permissions reviewed
☐ Access keys controlled
☐ CloudTrail enabled where appropriate
☐ Privileged activity monitored
☐ Access periodically reviewed

Prefer temporary role-based access over long-lived credentials where practical.

21. AWS Root Account

The AWS root account must be protected with enhanced controls.

☐ MFA enabled
☐ Root credentials securely stored
☐ Root access keys avoided
☐ Access limited to authorized personnel
☐ Root activity reviewed where applicable
☐ Emergency access process defined

Root access should only be used for activities that specifically require root-level privileges.

22. Production Access

Production access requires additional controls.

☐ Business justification
☐ System owner approval
☐ Least privilege
☐ MFA
☐ Named account
☐ Logging
☐ Monitoring
☐ Temporary access where appropriate
☐ Periodic review
☐ Access removal after task completion

Production access should not automatically be granted to all developers or technical personnel.

23. Database Access

Database access must be controlled based on role and need.

Consider:

Read access
Write access
Administrative access
Production access
Direct database access
Reporting access

☐ Named accounts
☐ MFA where supported/required
☐ Least privilege
☐ Logging
☐ Access review
☐ Credential protection

24. Source-Code Access

Access to source-code repositories must be controlled.

☐ Individual accounts
☐ MFA
☐ Repository-level permissions
☐ Branch protections where appropriate
☐ Administrative access restricted
☐ External collaborators reviewed
☐ Access reviewed periodically
☐ Departed users removed promptly

25. CI/CD Access

CI/CD systems can provide significant production capability and therefore require appropriate controls.

☐ Access restricted
☐ MFA
☐ Administrative access controlled
☐ Deployment permissions restricted
☐ Secrets protected
☐ Production deployment permissions controlled
☐ Service accounts restricted
☐ Logs maintained

26. SaaS Application Access

For critical SaaS applications:

☐ Application owner identified
☐ Users identified
☐ Roles defined
☐ MFA/SSO enabled where appropriate
☐ Privileged users identified
☐ External users reviewed
☐ Dormant accounts identified
☐ Access periodically reviewed

27. Remote Access

Remote access to organizational systems must be secured.

☐ Authorized users
☐ MFA
☐ Secure connection
☐ Device security
☐ Least privilege
☐ Logging
☐ Monitoring where appropriate
☐ Access review

28. VPN Access

Where VPN is used:

☐ Individual accounts
☐ MFA
☐ Access approval
☐ Least privilege
☐ Connection logging
☐ Periodic review
☐ Timely revocation

29. Temporary Access

Temporary access should be used where permanent access is unnecessary.

Examples:

Troubleshooting
Security testing
Vendor support
Incident response
Production deployment
Audit

Temporary access should have:

Defined purpose
Defined approver
Start time
Expiry time
Required permissions
Monitoring
Revocation

30. Emergency Access

Emergency access may be required during:

Security incidents
Major service outages
Critical vulnerabilities
Disaster recovery
Production emergencies

Emergency access should be:

Authorized → Limited → Monitored → Recorded → Reviewed → Revoked

Emergency access should be reviewed after the event.

31. Service Accounts

Service accounts must have defined ownership and purpose.

For each service account:

☐ Owner identified
☐ Purpose documented
☐ Permissions restricted
☐ Credentials protected
☐ Rotation defined
☐ Interactive login restricted where possible
☐ Monitoring enabled where appropriate
☐ Periodic review performed

32. API and Machine Access

Machine-to-machine access must be controlled.

Examples:

API keys
OAuth tokens
Service credentials
Cloud roles
Application credentials

Controls may include:

☐ Restricted permissions
☐ Secure storage
☐ Expiry
☐ Rotation
☐ Monitoring
☐ Revocation
☐ Ownership
☐ Usage restrictions

33. Third-Party Access

Supplier and contractor access must follow the same principles of authorization and least privilege.

Before granting access:

☐ Business need identified
☐ Supplier relationship approved
☐ Security requirements reviewed
☐ Named individual identified
☐ Appropriate approval obtained
☐ Access duration defined
☐ MFA enabled where appropriate
☐ Monitoring implemented where appropriate

34. Dormant Accounts

Periodically identify accounts that are:

Unused
Inactive
No longer required
Associated with former personnel
Associated with former suppliers

Dormant accounts should be disabled or removed according to organizational requirements.

35. Access Review

Access to important systems should be reviewed periodically.

Review:

☐ User identity
☐ Employment status
☐ Role
☐ Permissions
☐ Privileged access
☐ Production access
☐ External users
☐ Service accounts
☐ Temporary access
☐ Dormant accounts

Access Review Register

User	System	Access	Owner	Decision	Date
				Retain / Modify / Remove

36. Access Review Frequency

Frequency should be based on risk.

Example:

Access Type	Example Review Frequency
Privileged access	Monthly/Quarterly
Production access	Quarterly
Critical SaaS	Quarterly
Standard business applications	Semi-annual/Annual
Supplier access	Risk-based
Temporary access	At expiry
Emergency access	After use
Service accounts	Periodic/risk-based

These frequencies should be aligned with the organization’s actual risk and policy requirements.

37. Access Recertification

The reviewer should explicitly determine whether access should:

☐ Remain unchanged
☐ Be reduced
☐ Be expanded with approval
☐ Be transferred
☐ Be suspended
☐ Be removed

Simply completing an access-review checklist is not sufficient unless the review actually evaluates the appropriateness of access.

38. Segregation of Duties

Where relevant, prevent conflicting access combinations.

Examples:

Requester vs. approver
Developer vs. production approver
Payment creator vs. payment approver
User administrator vs. access reviewer
Security monitoring administrator vs. independent reviewer

Conflicting access should be:

☐ Prevented
☐ Controlled
☐ Monitored
☐ Formally approved where unavoidable

39. Sensitive Information Access

Access to sensitive information should receive enhanced controls.

Examples:

Customer information
Personal data
Financial information
Authentication information
Security information
Source code
Confidential business information

Apply:

Least privilege
Need-to-know
Authentication
Monitoring
Periodic review
Secure handling

40. Access Logging and Monitoring

Where appropriate, record:

☐ Login events
☐ Failed authentication
☐ Privileged activity
☐ Administrative changes
☐ Permission changes
☐ Access to sensitive systems
☐ Remote access
☐ API activity

Security-relevant access logs should be protected and retained according to organizational requirements.

41. Access Violations

Examples include:

Unauthorized access
Excessive privilege
Shared credentials
Bypassing approval
Access after termination
Unauthorized production access
Credential sharing

Such violations should be:

Recorded.
Assessed.
Contained where necessary.
Investigated.
Escalated according to severity.
Corrected.
Reviewed for recurrence.

42. Access Exceptions

Exceptions must be:

☐ Documented
☐ Business justified
☐ Risk assessed
☐ Approved
☐ Time-bound where appropriate
☐ Monitored
☐ Reviewed
☐ Closed or formally accepted

43. Access Revocation

Access must be revoked when:

Employment ends
Contract ends
Supplier relationship ends
Role changes
Business need ends
Access expires
Security risk requires removal
Account becomes unnecessary

Revocation Checklist

☐ User account disabled
☐ Privileged access removed
☐ Cloud access removed
☐ SaaS access removed
☐ VPN access removed
☐ Source-code access removed
☐ Database access removed
☐ API tokens addressed
☐ Access groups updated
☐ Shared credentials addressed where applicable
☐ Evidence recorded

44. Access Management Evidence

Maintain appropriate evidence such as:

☐ Access requests
☐ Approval records
☐ Account provisioning records
☐ IAM configuration
☐ MFA configuration
☐ Access reviews
☐ Access recertification
☐ Privileged access records
☐ Temporary access records
☐ Emergency access records
☐ Revocation records
☐ Joiner/mover/leaver records
☐ Access logs
☐ Exception records
☐ Corrective actions

Do not retain passwords, API keys, private keys, recovery codes, or other authentication secrets as ordinary audit evidence.

45. Access Findings

Finding ID	Area	Finding	Risk	Action	Owner	Due Date	Status

Examples:

Former employee account still active
Excessive administrator privileges
Missing MFA
Unused account
Unapproved external user
Permanent vendor access
Shared administrator account

46. Immediate Access Remediation

Where inappropriate access is identified:

Determine the risk.
Remove or restrict access where necessary.
Preserve relevant evidence.
Notify the responsible owner.
Investigate potential misuse where appropriate.
Record the issue.
Create corrective action.
Verify remediation.

47. Access Management Metrics

Possible metrics include:

Metric	Target	Frequency
Access review completion
MFA coverage
Privileged accounts reviewed
Leaver access revocation
Dormant accounts
Access exceptions
Unauthorized access events
Temporary access overdue
Supplier access reviewed

Metrics should support risk decisions rather than simply measure administrative activity.

48. Management Reporting

Significant access risks should be reported to appropriate management.

Examples:

Unresolved privileged access
Repeated access-control failures
Delayed leaver access removal
Excessive administrative access
Critical systems without MFA
Repeated unauthorized access attempts
High-risk supplier access

49. Access Management Review

The procedure should be reviewed based on:

Defined review frequency
Major system changes
Security incidents
Audit findings
Organizational changes
New applications
New cloud environments
New suppliers
Regulatory requirements
Changes in business processes

50. AWS SaaS Startup Example

Environment

A SaaS startup uses:

AWS
GitHub
Jira
Google Workspace/Microsoft 365
Production databases
CI/CD
Monitoring tools
Security tools

Developer Access

A developer requires:

GitHub repository access
Development AWS access
Jira access

The developer does not automatically receive production administrator access.

Production Access

A production access request requires:

Business Need → Manager Approval → System Owner Approval → Limited IAM Role → MFA → Logging → Temporary Access → Revocation

Example

A developer needs production access for a database troubleshooting task.

Request: Temporary production database read access

Duration: 2 hours

Approval: Engineering Manager + System Owner

Authentication: MFA

Permission: Read-only

Monitoring: Database/cloud logs

After task: Access automatically or manually revoked

Evidence: Ticket + approvals + IAM record + revocation evidence

51. Startup-Friendly Access Management Model

A startup can implement a simple but effective model.

Joiner

HR Notification → Manager Request → Approval → Provision → MFA → Record

Mover

Role Change → Review Existing Access → Remove Unnecessary Access → Add Required Access → Record

Leaver

Termination → Identify Access → Disable → Revoke → Verify → Record

Privileged Access

Need → Approval → MFA → Limited Permission → Monitor → Review

Temporary Access

Request → Approve → Time Limit → Monitor → Revoke

Periodic Review

Export Access → Review Owner → Validate Need → Remove Excess → Record

52. Common Mistakes

Avoid:

Granting access based only on verbal requests.
Giving users administrator access by default.
Using shared accounts.
Giving all developers production access.
Failing to remove access after role changes.
Delaying access revocation after termination.
Granting permanent supplier access.
Failing to use MFA for critical systems.
Not reviewing service accounts.
Ignoring API keys and machine identities.
Reviewing only user names without reviewing permissions.
Treating access-review completion as proof that access is appropriate.
Keeping temporary access permanently.
Storing passwords or secrets in access-review evidence.
Failing to investigate excessive privileges.

53. Relationship With Other ISMS Documents

Document	Relationship
Access Control Policy	Defines access-control requirements
IT Operations Procedure	Supports operational access management
Joiner/Mover/Leaver Procedure	Manages personnel lifecycle
Privileged Access Procedure	Controls administrative access
Cloud Security Policy	Governs cloud access
Supplier Security Procedure	Controls third-party access
Security Incident Procedure	Handles unauthorized access
Asset Register	Identifies systems requiring access
Risk Assessment	Identifies access-related risks
Access Review Checklist	Supports periodic review
Access Review Register	Records review decisions
Exception Register	Records approved deviations
Corrective Action Tracker	Tracks access weaknesses

54. ISO/IEC 27001 Connection

Access management supports the organization’s information-security risk treatment by ensuring that access to information and systems is appropriately authorized, restricted, authenticated, reviewed, and revoked.

The exact access controls and procedures required should be determined based on:

ISMS scope
Risk assessment
Risk treatment
Statement of Applicability
Applicable controls
Business requirements
System architecture
Information classification
Legal/regulatory requirements
Customer requirements
Contractual requirements

This Access Management Procedure is not itself a universally prescribed ISO/IEC 27001 document. The organization should maintain the documented information and operational evidence necessary to demonstrate that access is appropriately managed.

55. Audit Evidence Checklist

An auditor should be able to trace:

☐ Access policy
☐ Access procedure
☐ User access inventory
☐ Access requests
☐ Business justification
☐ Approvals
☐ Provisioning records
☐ MFA evidence
☐ Privileged access records
☐ Cloud access records
☐ Production access records
☐ Supplier access records
☐ Temporary access
☐ Joiner/mover/leaver records
☐ Periodic access reviews
☐ Revocation evidence
☐ Access logs
☐ Exceptions
☐ Findings
☐ Corrective actions

56. Final Access Management Audit Trail

For significant access, the organization should be able to demonstrate:

Who has access?

What system can they access?

What permissions do they have?

Why do they need the access?

Who approved it?

How was the access provisioned?

How is the user authenticated?

Is the access appropriately restricted?

Is privileged access separately controlled?

Is the access periodically reviewed?

When the business need ends, is the access removed?

What evidence demonstrates all of this?

Final Principle

Access management is not simply maintaining a list of users. It is continuously ensuring that every significant access right is justified, authorized, appropriately restricted, securely authenticated, monitored where appropriate, periodically reviewed, and removed when no longer required.