05 Access Control

Access control determines:

Who
      ↓
Can Access
      ↓
Which CDE Systems
      ↓
For What Purpose
      ↓
With What Level of Privilege

In a PCI DSS environment, access should not exist simply because:

User Is an Employee

or:

Administrator Might Need It

Access should be based on:

Business Need
      ↓
Approved Role
      ↓
Least Privilege
      ↓
Strong Authentication
      ↓
Ongoing Review

The objective is to reduce the possibility that unauthorized, excessive, shared, stale, or compromised identities can access systems that store, process, transmit, or protect payment account data.

A practical PCI access-control lifecycle looks like:

Identity
      ↓
Business Need
      ↓
Access Request
      ↓
Approval
      ↓
Provisioning
      ↓
Authentication
      ↓
MFA
      ↓
Usage
      ↓
Access Review
      ↓
Modification
      ↓
Termination

Learning Objectives

By the end of this lesson, you will be able to:

Explain PCI DSS access-control principles.
Understand need-to-know.
Understand least privilege.
Design role-based CDE access.
Understand unique user identification.
Understand authentication requirements.
Understand multi-factor authentication.
Identify privileged access.
Build privileged-access governance.
Manage user provisioning.
Manage transfers and role changes.
Manage user termination.
Understand temporary and emergency access.
Manage service accounts.
Understand shared and generic account risks.
Perform recurring access reviews.
Review CDE administrator access.
Build MFA coverage registers.
Test access-control effectiveness.
Collect PCI access-control evidence.
Identify common access-control gaps.
Build practical PCI access-control artifacts.

1. Why Access Control Matters

Payment environments are attractive targets because compromise of privileged or authorized accounts may provide access to:

PAN

Payment Applications

Databases

Encryption Keys

Security Configuration

Logs

An attacker does not always need to exploit software.

Sometimes the easiest path is:

Compromised Credential
      ↓
Authorized Account
      ↓
CDE Access

2. Access Control Principle

The basic principle is:

Access should be granted only to identities with a legitimate business need and only at the minimum level necessary to perform their assigned responsibilities.

Conceptually:

Identity
      +
Business Need
      +
Approved Role
      =
Authorized Access

3. Need to Know

Need-to-know means access is granted because the user requires it to perform legitimate duties.

Weak:

Finance Team
→ Full CDE Access

Strong:

Refund Analyst
→ Refund Function Only

4. Least Privilege

Least privilege means:

Minimum Permissions
Needed

rather than:

Maximum Permissions
for Convenience

5. Least Privilege Example

Weak:

Support Agent
→ Database Administrator

Strong:

Support Agent
→ Read-Only Customer Record View

6. Role-Based Access Control

Use defined roles where practical.

Example:

Payment Support

Payment Operations

Database Administrator

Security Analyst

Application Administrator

Each role should have documented permissions.

7. Build CDE Role Register

Create:

01 CDE Role Register

Use:

Role	Business Purpose	Systems	Privilege	Owner

8. Example Role

Role:

Payment Operations Analyst

Access:

Payment Application
→ Transaction View

Refund Function
→ Allowed

Database Admin
→ Not Allowed

9. Role Design

A role should answer:

What can this role access?

What can it do?

Who approves membership?

Who owns the role?

How often is it reviewed?

10. Excessive Role Design

Avoid:

PCI-ADMIN-ALL

granted widely.

Break privileges into appropriate operational roles.

11. Unique Identification

Every individual should generally use:

Unique User Identity

rather than:

Shared Username

Unique identities provide accountability.

12. Why Shared Accounts Are Risky

If:

admin

is used by five people, audit logs show:

admin changed configuration

but not:

which person

This weakens accountability.

13. Shared Account Example

Weak:

Username:
paymentadmin

Password:
Shared by Team

Stronger:

User:
alice.admin

User:
bob.admin

with individual authentication.

14. Generic Accounts

Examples:

administrator

root

oracle

support

may exist technically.

Where possible, users should authenticate individually and accountability should be preserved.

15. Root Accounts

On systems where:

root

exists, administrative access should ideally be:

Individual Identity
      ↓
Privilege Elevation
      ↓
Root Capability

rather than direct shared root logon.

16. Authentication

Authentication verifies:

Who Is the User?

Examples:

Password

Certificate

Hardware Token

Biometric

Security Key

17. Authentication Factor Categories

Common factors include:

Something You Know

Something You Have

Something You Are

18. Multi-Factor Authentication

MFA requires more than one distinct factor.

Example:

Password
      +
Security Key

19. MFA Is Not Two Passwords

Weak:

Password
+
Security Question

Both rely on knowledge.

That is not strong multi-factor authentication.

20. MFA in PCI Environments

MFA is especially important for access that can affect the CDE, including applicable administrative and remote-access scenarios.

For learning purposes, use the mindset:

CDE Access
      ↓
Strong Authentication
      ↓
MFA Where Required

21. MFA Coverage Register

Create:

02 MFA Coverage Register

Use:

Identity	Role	CDE Access	MFA	Exception

22. MFA Coverage Target

For identities subject to MFA:

Target:
100%

23. MFA Gap Example

Population:

45 CDE Administrators

MFA enabled:

Gap:

This requires investigation.

24. Authentication Centralization

A strong model may use:

Enterprise Identity Provider
      ↓
MFA
      ↓
CDE Systems

This provides centralized:

Policy

Logging

Access Revocation

Authentication

25. Local Accounts

Local accounts can create hidden access paths.

Examples:

Local Administrator

Local Database User

Local Service User

Inventory them.

26. Local Account Register

Maintain:

03 Local & Exceptional Account Register

Use:

Account	System	Owner	Purpose	MFA / Control	Review

27. Break-Glass Accounts

Organizations may need emergency accounts.

Example:

Identity Provider Unavailable
      ↓
Emergency Admin Access

Such accounts should be:

Restricted

Protected

Monitored

Tested

Reviewed

28. Break-Glass Governance

Document:

Owner

Purpose

Credential Storage

Authorization

Monitoring

Usage Review

29. Privileged Access

Privileged identities can:

Change Security Controls

Create Users

Modify Applications

Access Databases

Alter Logs

Manage Encryption

They require stronger governance.

30. Privileged Access Register

Create:

04 Privileged Access Register

Use:

User	Privileged Role	System	Business Need	Approver	Last Review

31. Privileged Access Principles

Use:

Separate Admin Identity

MFA

Least Privilege

Logging

Periodic Review

Time-Limited Access Where Possible

32. Separate Admin Accounts

Example:

rohit@example.com
→ Normal Work

and:

rohit-admin@example.com
→ Privileged Administration

This separates routine activity from privileged activity.

33. Privileged Access Management

Organizations may use PAM capabilities for:

Credential Vaulting

Session Control

Approval

Just-in-Time Access

Recording

34. Just-in-Time Privilege

Instead of:

Permanent Administrator

use:

Standard User
      ↓
Approved Request
      ↓
Temporary Admin
      ↓
Automatic Expiry

where feasible.

35. Standing Privilege Risk

Permanent privilege creates:

Larger Attack Window

because a compromised account retains powerful access continuously.

36. User Provisioning

New access should follow a controlled process.

Example:

Business Need
      ↓
Access Request
      ↓
Manager Approval
      ↓
System Owner Approval
      ↓
Provision
      ↓
Validate

37. Build User Provisioning Checklist

Create:

05 User Provisioning Checklist

Include:

User identified.
Role confirmed.
Business need documented.
Manager approval obtained.
System owner approval obtained.
Least privilege validated.
MFA enabled where required.
Provisioning evidence retained.

38. Access Request Evidence

Evidence may include:

Ticket

Requestor

Approver

Role

Date

Provisioning Record

39. Example Provisioning Control

Access to CDE systems is provisioned only after documented approval from the user’s manager and applicable system owner.

40. Access Approval Matrix

Create:

06 PCI Access Approval Matrix

Use:

Access Type	Manager	System Owner	Security	Additional Approval

41. Privileged Approval

Privileged access may require stronger approval than standard user access.

Example:

Manager
      +
System Owner
      +
Security

42. Role Changes

Employees change roles.

Example:

Developer
      ↓
Moves to
Security Team

Old access should not simply remain.

43. Mover Process

Use:

Role Change
      ↓
Reassess Existing Access
      ↓
Remove Old Access
      ↓
Provision New Access

44. Privilege Accumulation

Without mover controls:

Job 1 Permissions
      +
Job 2 Permissions
      +
Job 3 Permissions
      =
Excessive Access

45. Termination

Access should be promptly removed when no longer required.

Trigger:

Employee Leaves

Process:

HR Notification
      ↓
IAM Disable
      ↓
Application Removal
      ↓
Privileged Access Removal

46. Build Termination SLA Tracker

Create:

07 Termination SLA Tracker

Use:

User	Termination Time	Disable Time	SLA Met	Exception

47. Termination Testing

Example:

Population:

60 Terminations

Sample:

Verify:

Termination Date

Disablement Date

CDE Accounts

Privileged Roles

48. Contractor Terminations

Do not test only employees.

Include relevant:

Contractors

Temporary Workers

Third-Party Users

49. Dormant Accounts

Accounts not used for long periods can become attack paths.

Review:

Last Login

Owner

Business Need

50. Dormant Account Example

Account:
legacy-admin

Last Login:
14 Months Ago

Still Active:
Yes

Investigate.

51. Access Reviews

Access should be reviewed periodically.

Objective:

Does this person
still need this access?

52. Access Review Population

Review should use:

Complete User Population

not only selected users.

53. Access Review Register

Create:

08 Access Review Register

Use:

User	Role	Reviewer	Decision	Action	Date

54. Access Review Decisions

Use:

Retain

Modify

Remove

Investigate

55. Review Evidence

A strong review record demonstrates:

Complete Population

Reviewer

Review Date

Decision

Remediation

56. Weak Access Review Evidence

Weak:

Screenshot of User List

Stronger:

Population
+
Reviewer Sign-Off
+
Decisions
+
Removal Evidence

57. Privileged Access Reviews

Privileged users should receive special attention.

Review:

Admin Users

Database Admins

Cloud Admins

Firewall Admins

Security Admins

58. Service Accounts

Non-human identities include:

Service Accounts

Application Accounts

Workload Identities

API Accounts

59. Service Account Risks

Common issues:

No Owner

Permanent Credentials

Excessive Permission

Shared Secrets

No Review

60. Build Service Account Register

Create:

09 Service Account Register

Use:

Account	Purpose	System	Owner	Privilege	Credential Type	Review

61. Service Account Ownership

Every service identity should have:

Named Owner

even though the identity itself is not a person.

62. Workload Identity

Modern environments should prefer:

Short-Lived Workload Identity

over:

Permanent Static Password

where supported.

63. API Credentials

Protect:

API Keys

Tokens

Certificates

Secrets

Do not store them in:

Source Code

Email

Chat

Plaintext Files

64. Database Accounts

Review:

Application DB User

DBA Accounts

Reporting Accounts

Backup Accounts

65. Database Least Privilege

Application account may need:

SELECT

INSERT

UPDATE

but not necessarily:

DROP DATABASE

CREATE ADMIN

66. Cloud IAM

In cloud CDE environments review:

Users

Roles

Federation

Cross-Account Access

Service Roles

Permission Boundaries

67. Cloud Administrator Example

Weak:

Developer
→ AdministratorAccess

Strong:

Developer
→ Deployment Role
→ Limited Payment Resources

68. AWS Root Account

Cloud root or equivalent break-glass identities should be tightly controlled.

Use:

MFA

No Routine Use

Secure Credentials

Usage Alerts

69. Azure / Entra Roles

Review highly privileged identities such as:

Global Administrator

Privileged Role Administrator

when they can affect CDE access.

70. Kubernetes RBAC

For Kubernetes payment workloads review:

ClusterRole

RoleBinding

ServiceAccount

Namespace Access

71. Cluster Admin

Avoid widespread:

cluster-admin

access.

72. Kubernetes Least Privilege

Example:

Payment Developer
      ↓
Deploy to payments namespace

but:

Cannot Modify
Cluster Security Configuration

73. CI/CD Access

If CI/CD can deploy CDE applications, control:

Who Can Modify Pipelines?

Who Can Approve Production?

Which Credentials Are Used?

74. Repository Access

Code repositories for payment applications require:

Role-Based Access

MFA

Branch Protection

Review

75. Separation of Duties

Avoid placing incompatible responsibilities with one identity where risk warrants separation.

Example:

Developer
      ↓
Writes Code

Same Developer
      ↓
Approves Code

Same Developer
      ↓
Deploys Production

This may weaken change control.

76. Better Separation

Developer
      ↓
Creates Change

Peer Reviewer
      ↓
Approves

Deployment Pipeline
      ↓
Controlled Production Deployment

77. Temporary Access

Temporary CDE access may be needed for:

Incident Response

Maintenance

Migration

Vendor Support

78. Temporary Access Control

Use:

Request
      ↓
Approval
      ↓
Time-Bound Access
      ↓
Monitoring
      ↓
Automatic Expiry

79. Build Temporary Access Register

Create:

10 Temporary CDE Access Register

Use:

User	Reason	Privilege	Start	Expiry	Approver

80. Emergency Access

Emergency access should not become:

Permanent Shortcut

Review all emergency access after use.

81. Third-Party Access

External administrators may include:

Payment Vendor

Cloud Support

Managed Service Provider

82. Third-Party Access Requirements

Use:

Named User

MFA

Approved Need

Restricted Scope

Time Limit

Monitoring

83. Vendor Shared Accounts

Avoid:

vendoradmin

used by multiple vendor engineers.

Require individual accountability where possible.

84. Authentication Logging

Log:

Successful Authentication

Failed Authentication

Privilege Changes

Account Creation

Account Disablement

Repeated failures may indicate:

Brute Force

Credential Attack

Misconfiguration

86. Privilege Change Monitoring

Example:

User
      ↓
Granted Admin

should create:

Audit Record

and potentially alerting.

87. New Privileged Account Alert

A strong monitoring use case:

New CDE Administrator
      ↓
SIEM Alert
      ↓
Validate Approval

88. Authentication Evidence

Potential PCI evidence:

IAM Policies

MFA Configuration

User Population

Admin Population

Authentication Logs

Access Requests

Access Reviews

Termination Records

89. Access Control Matrix

Create:

11 PCI Access Control Matrix

Use:

Role	System	Read	Write	Admin	Approval Required

90. Example

Role	Payment App	Payment DB	Firewall
Support	Read	None	None
Payment Ops	Read/Write	None	None
DBA	None	Admin	None
Network Admin	None	None	Admin

91. Access Control Testing

A practical testing workflow:

Define Population
      ↓
Select Sample
      ↓
Verify Approval
      ↓
Verify Role
      ↓
Verify MFA
      ↓
Verify Current Need
      ↓
Document Result

92. Build Access Control Testing Checklist

Create:

12 PCI Access Control Testing Checklist

For each sampled user:

User is active employee/contractor.
Business need exists.
Approval exists.
Role matches job function.
Least privilege applied.
MFA enabled where required.
Privileged access separately approved.
Access still required.

93. Provisioning Test Example

Population:

80 New CDE Access Requests

Sample:

Result:

24 Approved Before Access

1 Missing Approval

Potential:

Access Control Exception

94. MFA Test Example

Population:

55 CDE Administrators

Result:

54 MFA

1 No MFA

Investigate immediately.

95. Termination Test Example

Population:

40 Departures

Sample:

Result:

18 Timely

2 Delayed

Perform root-cause analysis.

96. Access Review Test

Expected:

Quarterly Review

Evidence:

Q1 ✓
Q2 ✓
Q3 ✗
Q4 ✓

Potential operating gap.

97. Service Account Review Test

Population:

65 Service Accounts

Unknown owners:

Risk:

Unmanaged Non-Human Access

98. Dormant Admin Test

Population:

20 Admin Accounts

Dormant:

If unnecessary:

Disable

99. Access Finding — Excessive Privilege

Ten developers have database administrator access to the production payment database despite their job responsibilities requiring application deployment only.

Classification:

Least Privilege Gap

100. Access Finding — Shared Account

Six administrators use a shared local administrator account to manage payment servers.

Risk:

Loss of Individual Accountability

101. Access Finding — MFA

Two administrative accounts capable of accessing CDE systems are not protected by MFA.

102. Access Finding — Termination

Three contractor accounts remained active more than seven days after contract termination.

103. Access Finding — Access Review

Privileged user access has not been formally reviewed for nine months.

104. Access Finding — Service Account

Fifteen service accounts have no documented owner and use passwords that have not been changed or governed through an approved secrets process.

105. Build Access Control Gap Register

Create:

13 PCI Access Control Gap Register

Use:

Gap	Account / Role	Risk	Severity	Owner

106. Root Cause Example — Excessive Privilege

Problem:

Developers Have DBA Access

Why?

Old Support Requirement

Why?

Access Never Removed

Why?

No Role-Change Review

Root cause:

Access lifecycle management does not reassess CDE privileges when employees change responsibilities.

107. Correction

Remove Unnecessary DBA Access

108. Corrective Action

Integrate Role Change Events
      ↓
Access Re-Certification

109. Root Cause Example — Termination

Problem:

Contractor Account Remained Active

Why?

Contractor Not in HR Feed

Root cause:

Contractor lifecycle events are not integrated into the automated IAM termination workflow.

110. Corrective Action

Add Contractor Lifecycle Feed

Automate Disablement

Monitor SLA

111. Root Cause Example — Service Account

Problem:

Service Accounts Have No Owners

Root cause:

Non-human identities are not included in the enterprise identity-governance process.

112. Corrective Action

Service Account Inventory

Owner Assignment

Credential Governance

Periodic Review

113. Access Control Dashboard

Track:

Metric	Target
CDE Users With Current Approval	100%
MFA Coverage	100%
Privileged Accounts With Owner	100%
Service Accounts With Owner	100%
Terminations Within SLA	100%
Access Reviews Completed	100%
Shared Admin Accounts	0

114. Access KPI

Example:

Percentage of CDE accounts
with current approved business need

115. MFA KRI

Example:

CDE administrative identities
without MFA

Target:

116. Termination KRI

Example:

Terminated users
with active CDE access
past required timeline

117. Privileged Access KRI

Example:

Privileged CDE accounts
without current approved owner

118. Service Account KRI

Example:

CDE service identities
with unmanaged static credentials

119. Practical Activity — Build CDE Role Model

Use fictional organization:

CloudShop

Create roles for:

Payment Support

Payment Operations

Developer

DBA

Cloud Administrator

Security Analyst

Define:

Systems

Permissions

Approval

MFA

Review Frequency

120. Practical Activity — Review User Access

Users:

Alice
→ Payment Support

Bob
→ Developer + DBA

Carol
→ Security Analyst

David
→ Former Employee

Vendor01
→ Shared Vendor Admin

Identify gaps.

Expected observations include:

Bob
→ Potential Excessive Privilege

David
→ Active Terminated Account

Vendor01
→ Shared Account Risk

121. Practical Activity — MFA Review

Population:

32 CDE Users

MFA:

30 Enabled

2 Disabled

For each exception document:

Identity

Reason

Risk

Correction

Corrective Action

122. Practical Activity — Build Access Review

Create a fictional quarterly review for:

25 Users

Classify each as:

Retain

Modify

Remove

Investigate

123. Practical Activity — Review Service Accounts

Create:

10 Service Accounts

Include deliberate issues:

No Owner

Excessive Access

Static Password

Unused Account

Identify remediation.

124. Practical Activity — Termination Testing

Use:

20 Terminated Users

Include:

18 Timely

2 Delayed

Perform:

Condition

Risk

Root Cause

Corrective Action

Retest

125. Practical Activity — Privileged Access Review

Review:

Cloud Admins

DBAs

Firewall Admins

Payment Application Admins

For each determine:

Business Need?

MFA?

Separate Admin ID?

Current Approval?

Still Required?

126. PCI Access Control Checklist

Identity

Unique user IDs used.
shared user accounts eliminated where possible.
local accounts inventoried.
break-glass accounts controlled.

Authorization

business need documented.
least privilege applied.
role definitions documented.
access approvals retained.

Authentication

strong authentication used.
MFA implemented where required.
authentication policies centrally managed where possible.
failed authentication monitored.

Privileged Access

privileged users identified.
separate admin identities used.
MFA enabled.
privileged access reviewed.
standing privilege minimized.

Provisioning

access request recorded.
manager approval obtained.
system owner approval obtained.
correct role provisioned.
evidence retained.

Movers

role changes trigger review.
old access removed.
new access approved.
privilege accumulation monitored.

Terminations

HR / contractor events integrated.
accounts disabled promptly.
local accounts removed.
privileged access removed.
termination SLA monitored.

Access Reviews

complete populations reviewed.
reviewers assigned.
review dates recorded.
decisions documented.
removal actions completed.

Service Accounts

all accounts inventoried.
owner assigned.
purpose documented.
least privilege applied.
credentials secured.
usage reviewed.

Third Parties

individual identities used.
MFA enabled.
access approved.
access time-bound where appropriate.
activity monitored.

Evidence

user population available.
privileged population available.
MFA report available.
access requests retained.
termination records retained.
access-review evidence retained.

127. Common PCI Access-Control Mistakes

Mistake 1 — Everyone in IT Gets CDE Access

Business need and least privilege are ignored.

Mistake 2 — Shared Admin Accounts

Individual accountability is lost.

Mistake 3 — MFA Coverage Assumed

Local and emergency accounts are excluded from the population.

Mistake 4 — Privileges Never Reassessed

Users accumulate access over time.

Mistake 5 — Employee Termination Only

Contractors and vendors remain active.

Mistake 6 — Service Accounts Ignored

Non-human identities become unmanaged.

Mistake 7 — Access Review Is Only a User List

No reviewer decisions are documented.

Mistake 8 — Temporary Access Never Expires

Emergency access becomes permanent.

Mistake 9 — CI/CD Permissions Ignored

Developers can change CDE applications indirectly.

Mistake 10 — Cloud Admin Scope Too Broad

Enterprise cloud administrators have unrestricted CDE control.

128. Weak Access-Control Model

Employee
      ↓
Requests Access
      ↓
Gets Admin
      ↓
Keeps Forever

129. Strong Access-Control Model

Identity
      ↓
Business Need
      ↓
Approved Role
      ↓
Least Privilege
      ↓
MFA
      ↓
Monitoring
      ↓
Periodic Review
      ↓
Role Change / Termination
      ↓
Access Removed

130. GRC Analyst Responsibilities

A GRC professional supporting PCI access control may:

Maintain CDE role definitions.
Maintain access-control matrices.
Review privileged-access populations.
Coordinate MFA coverage assessments.
Review provisioning workflows.
Review mover processes.
Monitor termination SLAs.
Coordinate access reviews.
Maintain service-account inventories.
Review third-party access.
Coordinate access-control testing.
identify access gaps.
track remediation.
maintain evidence.
support QSA access-control reviews.

GRC connects:

IAM

HR

Security

Cloud

Database Teams

Network Teams

Engineering

DevOps

Payment Operations

Third Parties

Assessors

131. Access-Control Maturity Model

Level 1 — Manual

Email Request

Manual Provisioning

Manual Removal

Level 2 — Controlled

Roles

Approvals

MFA

Access Reviews

Level 3 — Governed

IAM Workflow

Privileged Access Governance

Service Account Inventory

Termination SLA

Level 4 — Automated

HR Integration

Automated Provisioning

JIT Access

Automated Reviews

Level 5 — Continuous Identity Assurance

Continuous Entitlement Analysis

Real-Time MFA Coverage

Automatic Risk-Based Revocation

Workload Identity Governance

132. PCI Access-Control Mindset

For every CDE identity ask:

Who is this identity?

Is it a person or workload?

Who owns it?

Why does it need access?

Who approved it?

What systems can it access?

What can it do?

Is this the minimum privilege required?

Is MFA required?

Is MFA enabled?

Is the account shared?

When was access last reviewed?

When was it last used?

What happens when the person changes roles?

What happens when they leave?

Can we prove all of this?

For every privileged identity ask:

Does this privilege need
to exist all the time?

If not:

Reduce Standing Privilege

When these questions can be answered with reliable evidence, access to the CDE becomes controlled, accountable, and testable.

Key Takeaways

PCI access should be based on business need and least privilege.
Unique identities support accountability.
Shared administrative accounts should be minimized or eliminated where possible.
Role-based access simplifies consistent authorization.
MFA is critical for applicable CDE and administrative access scenarios.
Local and emergency accounts must be included in identity governance.
Privileged access should receive stronger controls and more frequent attention.
Provisioning should require documented approval.
Role changes should trigger access reassessment.
Terminated employees, contractors, and third parties should have access promptly removed.
Periodic access reviews should use complete populations and document reviewer decisions.
Service accounts and workload identities require ownership, least privilege, and credential governance.
Temporary access should be approved, monitored, and automatically expire where possible.
CI/CD, cloud, Kubernetes, and other modern platforms create indirect paths to CDE privilege.
Access-control testing should validate approval, role, privilege, MFA, ongoing need, and timely removal.
GRC coordinates identity populations, evidence, reviews, testing, gaps, and assessor support.

Knowledge Check

Before continuing, make sure you can answer:

What does least privilege mean?
What is need-to-know?
Why are role definitions important?
Why should users have unique IDs?
What is wrong with shared administrator accounts?
What is MFA?
Why should local accounts be inventoried?
What is a break-glass account?
What is privileged access?
Why are separate administrative identities useful?
What is just-in-time access?
What evidence should support provisioning?
Why should role changes trigger access review?
Why must contractor terminations be included?
What makes an access review effective?
Why are service accounts important?
Why can CI/CD access be privileged?
How should third-party CDE access be controlled?
What should an access-control test verify?
What role does GRC play in PCI access-control assurance?

What’s Next?

➡️ Next: 06 — Vulnerability Management

In the next lesson, you will move from identity and access controls into protecting CDE systems from known vulnerabilities and malicious software.

You will work through:

Asset Inventory
      ↓
Vulnerability Discovery
      ↓
Risk Classification
      ↓
Security Patching
      ↓
Remediation SLA
      ↓
Malware Protection
      ↓
Internal Scanning
      ↓
External ASV Scanning
      ↓
Exceptions
      ↓
Retesting
      ↓
Continuous Monitoring

You will also build practical artifacts including a PCI Vulnerability Management Standard, CDE Vulnerability Register, Patch Compliance Dashboard, Vulnerability SLA Tracker, ASV Scan Register, Malware Protection Coverage Register, Risk Exception Register, Vulnerability Retest Register, and PCI Vulnerability Management Testing Checklist.