1. Purpose

The Privileged Identity Management (PIM) Procedure defines how the organization identifies, requests, approves, provisions, uses, monitors, reviews, and removes privileged identities and elevated access.

Privileged access can provide the ability to change security configurations, access sensitive information, modify production systems, create users, change permissions, or disable security controls. It therefore requires stronger governance than normal user access.

Core Principle

Identify → Justify → Approve → Grant → Protect → Use → Monitor → Review → Revoke

---

2. Scope

This procedure applies to privileged identities and elevated access used by:

• Employees
• Contractors
• Consultants
• IT administrators
• Cloud administrators
• Security administrators
• Database administrators
• Network administrators
• DevOps engineers
• System administrators
• Application administrators
• Third-party support personnel
• Service accounts
• Emergency/break-glass accounts

It may cover:

• AWS
• Azure
• Google Cloud
• Identity providers
• Servers
• Databases
• Network devices
• Firewalls
• Security platforms
• SaaS administration consoles
• Source-code repositories
• CI/CD platforms
• Backup platforms
• Endpoint management
• Encryption/key-management systems
• Secrets-management platforms
• Customer environments

---

3. What Is Privileged Access?

Privileged access is access that allows a user or identity to perform administrative, security-sensitive, or high-impact actions beyond ordinary business-user permissions.

Examples include:

• Creating or deleting accounts
• Changing permissions
• Managing administrators
• Modifying production systems
• Accessing production databases
• Changing firewall rules
• Managing encryption keys
• Accessing security logs
• Modifying security configurations
• Deploying production code
• Disabling monitoring
• Managing backups
• Changing cloud infrastructure

Privilege should be determined based on the organization’s systems and risk rather than relying only on the account name.

---

4. Privileged Identity Types

Identity Type	Example
Human Privileged Identity	Cloud Administrator
Dedicated Admin Account	admin.smith
Privileged Cloud Role	AWS Administrator Role
Database Admin Identity	DBA Administrator
Network Admin	Firewall Administrator
Security Admin	SIEM/Security Platform Administrator
CI/CD Privileged Identity	Production Deployment Role
Service Account	Infrastructure Automation
Emergency Identity	Break-Glass Administrator
Third-Party Privileged Identity	Vendor Support Administrator

---

5. Privileged Identity Management Lifecycle

The lifecycle should follow:

Identify Need

↓

Risk Assessment

↓

Request

↓

Approval

↓

Create/Enable Privileged Identity

↓

Assign Minimum Required Privileges

↓

Protect Authentication

↓

Use Privileged Access

↓

Monitor

↓

Review

↓

Reduce/Modify

↓

Revoke/Disable

↓

Record Evidence

---

6. Privileged Access Principles

The organization should apply:

Least Privilege

Grant only the permissions required for the approved task.

Need-to-Know

Access to sensitive information should be limited to legitimate business requirements.

Individual Accountability

Privileged activities should be attributable to an individual wherever technically possible.

Separation of Duties

Where practical, requesting, approving, implementing, and reviewing privileged access should not all be performed by the same person.

Strong Authentication

Privileged identities should use stronger authentication controls appropriate to their risk.

Time Limitation

Privileged access should be temporary where practical.

Monitoring

Privileged activity should be logged and monitored where technically feasible.

Periodic Review

Privileged access should be reviewed regularly.

---

7. Privileged Access Request

Privileged access should require a documented request.

Minimum fields:

Field	Description
Request ID	Unique identifier
Requestor	Person requesting access
Identity	User/account
System	Target system
Environment	Production/Test/Development
Privilege Requested	Role/permission
Business Purpose	Why required
Duration	Permanent/Temporary
Start Date	Access start
Expiry Date	If applicable
Information Accessed	Data/resources
Classification	Information classification
Risk	Risk assessment
System Owner	System owner
Manager	Requestor manager
Security Approval	Where required
Status	Pending/Approved/Rejected

---

8. Privileged Access Approval

Approval should be based on:

• Business need
• Role
• System criticality
• Information classification
• Privilege level
• Duration
• Risk
• Existing permissions
• Separation-of-duties considerations
• Security requirements

A typical approval flow is:

Requestor → Manager → System Owner → Security/Data Owner → Authorized Approver

Not every request requires every approval level; the organization should define its approval thresholds.

---

9. Dedicated Privileged Accounts

Where practical, administrative activities should use dedicated privileged identities rather than the user’s normal business account.

Example:

Normal account

user@company.com

for:

• Email
• Collaboration
• Routine business applications

Privileged identity

user-admin@company.com

for:

• Cloud administration
• Identity administration
• Security administration

This separation can reduce the risk of accidental or unauthorized use of administrative privileges.

---

10. Just-In-Time Privileged Access

Where the technology supports it, privileged access should be granted only for the required period.

Example:

Request → Approval → Privilege Activated → Perform Task → Privilege Automatically Expires

This can reduce standing administrative access.

Just-in-time access is a risk-reduction technique and should be implemented where practical based on technology, cost, and risk.

---

11. Permanent Privileged Access

Permanent privileged access should be limited to roles that genuinely require ongoing administration.

Examples may include:

• Cloud platform administrator
• Identity administrator
• Security administrator
• Infrastructure administrator

For permanent privileged access:

• Document the justification.
• Assign an owner.
• Apply strong authentication.
• Apply least privilege.
• Monitor where appropriate.
• Review periodically.
• Remove when the role changes.

---

12. Privileged Access to AWS

For an AWS environment, privileged access should preferably use centralized identity and role-based access mechanisms.

Example:

Administrator

→ SSO

→ MFA

→ Approved AWS Role

→ Specific AWS Account

→ Required Permissions

→ CloudTrail Logging

→ Security Monitoring

Where practical:

• Avoid sharing root credentials.
• Avoid using long-lived access keys for human administrators.
• Use roles.
• Use MFA.
• Separate production and non-production environments.
• Restrict administrative permissions.
• Log privileged activity.
• Review privileged roles regularly.

---

13. AWS Root Account

The AWS root account is highly sensitive and should be separately controlled.

Recommended practices include:

• Restrict routine use.
• Protect root credentials securely.
• Enable strong authentication.
• Do not use root credentials for normal administration.
• Monitor use where possible.
• Maintain controlled recovery information.
• Document exceptional root-account use.

Root-account access should be treated as a high-risk administrative identity.

---

14. Privileged Database Access

Database administrators and other users with elevated database permissions should be managed separately.

Controls may include:

• Named administrative accounts
• MFA where supported
• Least privilege
• Production restrictions
• Logging
• Monitoring
• Temporary access
• Access reviews
• Separation of administrative and normal user access

Avoid giving an administrator unrestricted access to all databases when their responsibilities only require specific databases.

---

15. Privileged Source-Code Access

Privileged repository permissions may include:

• Repository administration
• Branch protection administration
• Organization administration
• Deployment permissions
• Secrets administration
• Repository deletion

These permissions should be limited to authorized personnel.

Production deployment permissions should be separately evaluated because they can directly affect production systems.

---

16. Privileged CI/CD Access

CI/CD systems may contain high-impact privileges.

Review:

• Pipeline administration
• Production deployment
• Secret access
• Runner administration
• Repository integration
• Cloud deployment roles

Controls may include:

• Named administrators
• MFA
• Protected branches
• Approval gates
• Restricted deployment roles
• Short-lived credentials
• Pipeline logging
• Periodic review

---

17. Service Account Privileges

Service accounts can also be privileged.

Examples:

• Infrastructure automation
• Backup administration
• Deployment automation
• Security automation
• Database maintenance

For privileged service accounts:

• Document the purpose.
• Assign an owner.
• Define permissions.
• Protect credentials.
• Prefer workload identity/roles where practical.
• Monitor activity where appropriate.
• Review periodically.
• Remove when no longer required.

Privileged service accounts should also be recorded in the Service Account Register and, where applicable, the Privileged Access Register.

---

18. Contractor and Third-Party Privileged Access

Third-party privileged access should receive additional scrutiny.

Before granting access:

• Verify the contractor/vendor.
• Confirm contract/SOW.
• Confirm NDA/security requirements.
• Identify business purpose.
• Define exact permissions.
• Define duration.
• Obtain appropriate approval.
• Enable MFA.
• Use named accounts.
• Monitor where appropriate.

Where practical:

Grant → Perform Task → Verify → Revoke

rather than maintaining permanent third-party administrative access.

---

19. Emergency / Break-Glass Access

Emergency identities may be required when normal administrative access is unavailable.

Examples:

• Identity provider outage
• Critical cloud failure
• Security incident
• Emergency recovery
• Loss of normal administrator access

Emergency accounts should:

• Have a documented purpose.
• Be tightly protected.
• Have limited authorized users.
• Be stored securely.
• Be monitored where possible.
• Be tested periodically.
• Be reviewed after use.

Emergency Use

Emergency → Activate → Perform Required Action → Record Activity → Review → Rotate Credentials if Applicable → Disable/Return to Controlled State

Emergency access should not become an alternative to normal access-management processes.

---

20. Privileged Credential Management

Privileged credentials should be protected using approved mechanisms.

Examples:

• Enterprise password vault
• Secrets-management platform
• Cloud-native secrets management
• Federated identity
• Short-lived credentials
• Hardware security mechanisms where appropriate

Do not store privileged credentials in:

• Spreadsheets
• Email
• Chat
• Source code
• Tickets
• Unprotected documents
• Personal password managers unless explicitly approved

---

21. Privileged Credential Rotation

Where passwords, keys, tokens, or certificates are used, appropriate rotation should be implemented.

Rotation may be triggered by:

• Scheduled rotation
• Personnel departure
• Privilege change
• Suspected compromise
• Credential exposure
• Vendor change
• Security incident
• Emergency access use

The organization should maintain evidence that required credential-management activities occurred.

---

22. Privileged Session Management

Where appropriate, privileged sessions may be subject to:

• Session logging
• Command logging
• Activity monitoring
• Session recording
• Source-IP restrictions
• Time restrictions
• Network restrictions
• Alerting

The level of monitoring should be proportionate to the risk and technical capability.

---

23. Privileged Activity Monitoring

Monitor relevant privileged activity such as:

• Creation of administrators
• Permission changes
• IAM policy changes
• Security configuration changes
• Firewall changes
• Production deployments
• Database administration
• Key-management changes
• Security logging changes
• Monitoring disablement
• Backup configuration changes
• Unusual administrative activity

In AWS, relevant activity may be recorded through CloudTrail and other applicable monitoring/security services.

---

24. Privileged Access Review

Privileged identities should be periodically reviewed.

Review:

• User/identity
• Role
• Business justification
• System
• Permissions
• Environment
• Information accessed
• Last activity
• MFA
• Monitoring
• Start/expiry date
• Continued business need

Possible outcomes:

Retain → Reduce → Modify → Suspend → Revoke

---

25. Privileged Access Review Frequency

The organization should define review frequency based on risk.

For example:

Privilege	Example Review
Critical Production Admin	Monthly
Cloud Administrator	Monthly/Quarterly
Security Administrator	Monthly/Quarterly
Database Administrator	Quarterly
Development Administrator	Quarterly
Temporary Privileged Access	At expiry/after use
Emergency Account	Periodically + after every use

These frequencies are examples, not universal ISO requirements.

---

26. Privilege Changes

When a person’s role changes:

Role Change → Identify Existing Privileges → Reassess → Remove Unnecessary Privileges → Approve New Privileges → Provision → Verify

Never simply add new privileges without reviewing existing privileges.

This prevents privilege accumulation.

---

27. Privileged Access Revocation

Privileged access should be revoked when:

• Employment ends.
• Contractor engagement ends.
• Role changes.
• Project ends.
• Business need ends.
• Access expires.
• Security incident requires removal.
• Credentials are compromised.
• Access is no longer justified.

Revocation should include, where applicable:

• Admin accounts
• Cloud roles
• IAM permissions
• Database privileges
• Repository administration
• VPN
• SaaS administration
• API keys
• SSH keys
• Tokens
• Certificates
• Active sessions

---

28. Privileged Identity Offboarding

The offboarding process should be:

Exit/Role Change Notification

→ Identify Privileged Identities

→ Disable/Revoke

→ Terminate Sessions

→ Revoke Tokens/Keys

→ Remove Group Memberships/Roles

→ Verify

→ Update Privileged Access Register

→ Record Evidence

---

29. Privileged Access Exceptions

Exceptions may include:

• Legacy systems
• Shared administrative identities
• Technical limitations
• Emergency requirements
• Vendor-required administrative access

Document:

Field	Description
Exception ID	Unique identifier
Identity	Privileged identity
System	System
Exception	What is different
Reason	Business/technical reason
Risk	Risk
Compensating Control	Additional control
Owner	Responsible person
Approval	Authorized approval
Expiry/Review	Review date
Status	Open/Closed

Exceptions should be periodically reassessed.

---

30. Privileged Identity Register

The organization should maintain a centralized register.

Recommended fields:

Field	Description
Privileged ID	Unique identifier
Identity	User/service identity
Identity Type	Human/Service/Emergency
Owner	Responsible person
System	Target system
Environment	Prod/Test/Dev
Privileged Role	Administrator role
Permissions	Key permissions
Business Purpose	Justification
Information Accessed	Data/resources
Classification	Information classification
MFA	Yes/No
Access Type	Permanent/Temporary
Start Date	Start
Expiry Date	Expiry
Last Activity	Last use
Last Review	Review date
Next Review	Next review
Monitoring	Monitoring status
Status	Active/Disabled/Revoked
Related Request	Request ID
Related Risk	Risk ID
Evidence	Evidence location

This register complements the broader Identity Register.

---

31. Relationship with Service Accounts

A service account can also be privileged.

For example:

svc-deployment-prod

may have permission to deploy code to production.

In that case:

Service Account Register

records:

• Purpose
• Application
• Owner
• Credential management
• Lifecycle

while the Privileged Access Register records:

• Privileged nature
• Permissions
• Approval
• Review
• Privilege level

This provides better traceability.

---

32. Privileged Access and Segregation of Duties

Privileged access should be evaluated for incompatible responsibilities.

Examples:

• Developer + unrestricted production deployment
• Requestor + approver
• Administrator + independent reviewer
• Security configuration administrator + audit approval

Where complete separation is impractical, use compensating controls such as:

• Independent review
• Approval gates
• Logging
• Monitoring
• Periodic review
• Automated controls

---

33. Privileged Access and Change Management

Privileged users should not bypass normal change-management requirements merely because they have administrative access.

Where applicable:

Change Request → Approval → Privileged Action → Testing → Verification → Change Evidence

Emergency changes should follow the organization’s emergency-change process.

---

34. Privileged Access During Security Incidents

During a security incident, privileged access may need to be increased temporarily.

For example:

• Incident responder requires emergency cloud access.
• Security team needs additional log access.
• Compromised administrator accounts need immediate restriction.

Any temporary elevated access should be:

• Authorized.
• Limited to the incident.
• Logged.
• Monitored where practical.
• Reviewed after the incident.
• Revoked when no longer required.

---

35. AWS SaaS Startup Example

Consider a SaaS company operating its production environment on AWS.

Normal Developer

Developer → SSO + MFA → Developer Role → Development Account

Production Administrator

DevOps Lead → SSO + MFA → Approved Production Role → Required AWS Resources

Emergency Access

Authorized Responder → Emergency Approval → Break-Glass Role → Incident Response → Activity Review → Disable/Restrict

Deployment

CI/CD → Workload Identity → Limited Deployment Role → Approved Production Resources

The objective is to avoid giving every developer permanent AWS administrator privileges.

---

36. Metrics

Useful PIM metrics may include:

• Number of privileged identities
• Number of privileged human users
• Number of privileged service accounts
• Percentage with MFA
• Percentage with assigned owners
• Percentage reviewed on schedule
• Number of dormant privileged identities
• Number of expired privileges
• Number of privilege exceptions
• Number of emergency access events
• Number of privileged access violations
• Number of unnecessary privileges removed
• Average time to revoke privileged access

Metrics should support management decisions rather than becoming a compliance exercise.

---

37. Audit Evidence

Evidence may include:

• Privileged Identity Register
• Privileged Access Register
• Access requests
• Approval records
• IAM/SSO configuration
• AWS IAM/Identity Center records
• MFA configuration
• Role/permission configurations
• CloudTrail logs
• Session/activity logs
• Access review reports
• Credential rotation evidence
• Change records
• Emergency access records
• Offboarding records
• Revocation records
• Exception records
• Risk assessments

Never store actual passwords, API keys, private keys, recovery codes, or other secrets in audit evidence.

---

38. Roles and Responsibilities

Role	Responsibility
Privileged User	Use privileged access only for authorized activities
Manager	Validate business need
System Owner	Approve system privileges
Data Owner	Approve sensitive-data access where required
Security/ISMS	Define oversight and security requirements
IT/IAM	Provision and revoke identities
Cloud Team	Manage cloud privileges
Application Owner	Manage application administration
HR/People	Notify role changes and departures
Internal Audit	Independently assess control effectiveness
Management	Approve significant risk decisions

---

39. Startup-Friendly PIM Model

A startup does not necessarily need a dedicated enterprise PIM platform on day one.

A practical minimum model is:

1. Identify

Maintain a Privileged Access Register.

2. Restrict

Use role-based access and least privilege.

3. Protect

Use MFA and secure credential storage.

4. Approve

Require documented approval for privileged access.

5. Monitor

Enable available cloud/system logging.

6. Review

Review privileged identities periodically.

7. Revoke

Remove privileged access immediately when the business need ends.

8. Improve

Use review findings and incidents to reduce unnecessary privileges.

---

40. Common Mistakes

Avoid:

• Giving every IT employee administrator access.
• Using one shared administrator account.
• Permanent contractor administrator access.
• Long-lived cloud access keys for humans.
• No MFA for privileged accounts.
• No owner for privileged identities.
• No documented business justification.
• Giving production access by default.
• Failing to review old privileges.
• Adding privileges without removing old ones.
• Ignoring privileged service accounts.
• Leaving emergency accounts uncontrolled.
• Storing administrator credentials in spreadsheets.
• Failing to review privileged activity after incidents.
• Treating access approval as permanent authorization.

---

41. Quick Audit Checklist

Identification

• All privileged identities identified
• Human and service identities identified
• Emergency identities identified
• Third-party privileged identities identified
• Owners assigned

Approval

• Business justification documented
• Access request completed
• Appropriate approval obtained
• Risk assessed
• SoD considered

Protection

• MFA enabled where supported
• Least privilege applied
• Dedicated admin identities used where appropriate
• Credentials securely stored
• Privileged accounts protected
• Temporary access expires appropriately

Monitoring

• Privileged activity logged where appropriate
• Monitoring configured based on risk
• Emergency access reviewed
• Significant privileged activity investigated where required

Review

• Privileged access reviewed periodically
• Dormant privileges identified
• Excessive privileges removed
• Role changes trigger reassessment

Revocation

• Leaver access revoked
• Contractor access revoked
• Expired access removed
• Tokens/keys addressed
• Active sessions addressed
• Revocation verified
• Evidence retained

---

42. Relationship with the ISMS

The Privileged Identity Management Procedure should connect with:

Identity Management Policy

→ User Account Management Procedure

→ Identity Register

→ Privileged Access Register

→ Service Account Register

→ Access Control Matrix

→ Access Review Report

→ JML Procedure

→ Contractor Account Procedure

→ Access Revocation Checklist

→ Change Management

→ Incident Management

→ Risk Register

→ Internal Audit

This creates an end-to-end control trail.

---

43. ISO 27001 Connection

The procedure supports applicable ISO/IEC 27001 information-security controls relating to:

• Identity management
• Authentication
• Access rights
• Privileged access
• Restriction of access
• Segregation of duties
• Logging and monitoring
• Configuration/change management
• Supplier access
• Incident management

The exact controls applicable to the organization should be determined through its information-security risk assessment and Statement of Applicability (SoA).

---

44. Final Audit Trail

For every privileged identity, the organization should be able to demonstrate:

Who has privileged access?

→ Why do they need it?

→ Who approved it?

→ What system can they administer?

→ What permissions do they have?

→ How is the identity protected?

→ Is the activity logged/monitored appropriately?

→ When was the access last reviewed?

→ Is the privilege still required?

→ What happens when the person or service no longer needs it?

→ Was access actually removed?

→ Is evidence available?

Final Principle

Privileged access should be rare, justified, individually attributable where practical, strongly protected, limited to the minimum required, monitored according to risk, periodically reviewed, and promptly removed when the business need ends.