Role-Based Screening Matrix

1. Purpose

The Role-Based Screening Matrix defines the background verification and screening requirements applicable to different roles based on their responsibilities, access, information exposure, and associated security risk.

The matrix helps the organization apply a risk-based and proportionate approach rather than performing identical background checks for every individual.

Core Principle

Role → Access → Information → Risk → Screening Level → Verification → Approval

2. Scope

This matrix may be applied to:

Employees
Contractors
Consultants
Interns
Temporary personnel
Outsourced personnel
Third-party personnel
Privileged users
Security-sensitive personnel
Personnel moving into higher-risk roles

The matrix should be adapted to applicable legal, regulatory, contractual, privacy, and customer requirements.

3. Screening Level Definitions

Level	Description
Level 1 – Basic	Basic identity and role-related verification
Level 2 – Standard	Basic verification plus employment, education/qualification, and references where relevant
Level 3 – Enhanced	Standard verification plus additional lawful checks appropriate to the role
Level 4 – High Risk	Enhanced verification with additional approval and role-specific checks

The organization should not automatically perform every available check at every level.

4. Screening Check Definitions

Code	Screening Check
ID	Identity verification
ADDR	Address verification where relevant
EMP	Employment verification
EDU	Education/qualification verification
REF	Professional reference
PROF	Professional certification/license/registration verification
CR	Criminal-record check where lawful and relevant
REG	Regulatory/sanctions screening where applicable
FIN	Financial check where lawful and relevant to the role
RTW	Right-to-work verification where applicable
COI	Conflict-of-interest declaration
SEC	Additional security-sensitive role assessment
ENH	Enhanced verification/review

5. Role-Based Screening Matrix

Role / Position	Risk	Level	ID	EMP	EDU	REF	PROF	CR*	REG*	FIN*	COI	SEC
Intern – General	Low	1	✓	✓	Where relevant	Optional	N/A	N/A	N/A	N/A	Where relevant	N/A
Administrative Staff	Low	1	✓	✓	Where relevant	Optional	N/A	N/A	N/A	N/A	Where relevant	N/A
Marketing Staff	Low	1–2	✓	✓	Where relevant	Where relevant	N/A	N/A	N/A	N/A	✓	N/A
HR Staff	Medium	2	✓	✓	✓	✓	Where relevant	Where lawful/relevant	N/A	N/A	✓	✓
Finance Staff	Medium/High	2–3	✓	✓	✓	✓	Where relevant	Where lawful/relevant	Where applicable	Where lawful/relevant	✓	✓
Sales Staff	Medium	2	✓	✓	✓	✓	Where relevant	N/A	Where applicable	N/A	✓	N/A
Customer Support	Medium	2	✓	✓	Where relevant	Where relevant	N/A	Where lawful/relevant	N/A	N/A	✓	✓
Business Operations	Medium	2	✓	✓	Where relevant	✓	Where relevant	Where lawful/relevant	Where applicable	N/A	✓	✓
Software Developer	Medium	2–3	✓	✓	✓	✓	Where relevant	Where lawful/relevant	N/A	N/A	✓	✓
Senior Developer	Medium/High	3	✓	✓	✓	✓	✓	Where lawful/relevant	N/A	N/A	✓	✓
DevOps Engineer	High	3	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
Cloud Administrator	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
AWS Production Administrator	High/Critical	4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
Database Administrator	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
Security Engineer	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
SOC Analyst	High	3	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
CISO / Security Head	High/Critical	4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	Where relevant	✓	✓
IT Administrator	High	3	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
System Administrator	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
Network Administrator	High	3	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
Source Code Administrator	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	N/A	N/A	✓	✓
CI/CD Administrator	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	N/A	N/A	✓	✓
Product Manager	Medium	2	✓	✓	✓	✓	Where relevant	N/A	N/A	N/A	✓	Where relevant
Project Manager	Medium	2	✓	✓	✓	✓	Where relevant	N/A	N/A	N/A	✓	Where relevant
Compliance Manager	High	3	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
Internal Auditor	High	3	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	Where relevant	✓	✓
External Auditor	High	3	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	Where relevant	✓	✓
VAPT Consultant	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
vCISO / Security Consultant	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	Where relevant	✓	✓
Contractor – General	Medium	2	✓	✓	Where relevant	Where relevant	Where relevant	Where lawful/relevant	Where applicable	N/A	✓	✓
Contractor – Production Access	High	3–4	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
Third-Party Support Engineer	High	3	✓	✓	✓	✓	✓	Where lawful/relevant	Where applicable	N/A	✓	✓
Temporary Worker – General	Low/Medium	1–2	✓	✓	Where relevant	Optional	N/A	Where lawful/relevant	N/A	N/A	✓	Where relevant
Executive / Senior Management	High	3	✓	✓	✓	✓	Where relevant	Where lawful/relevant	Where applicable	Where lawful/relevant	✓	✓
Director / Partner	High	3–4	✓	✓	✓	✓	Where relevant	Where lawful/relevant	Where applicable	Where relevant	✓	✓

* Criminal-record, regulatory, sanctions, and financial checks should only be performed where lawful, relevant, proportionate, and appropriately authorized.

6. Information Access-Based Screening

Role title alone should not determine the screening requirement.

Consider the highest level of access.

Access Type	Typical Risk	Screening Consideration
Public information	Low	Basic
Internal information	Low/Medium	Basic/Standard
Confidential information	Medium	Standard
Restricted information	High	Enhanced
Customer personal data	Medium/High	Standard/Enhanced
Financial information	High	Enhanced where relevant
Source code	Medium/High	Standard/Enhanced
Production systems	High	Enhanced
AWS administration	High	Enhanced
Privileged IAM access	High/Critical	High Risk
Security infrastructure	High/Critical	High Risk
Cryptographic keys	High/Critical	High Risk
Regulatory systems	High	Enhanced/High Risk

7. Privileged Access Screening

Where an individual receives privileged access, assess:

☐ Role risk
☐ Identity verification
☐ Employment verification
☐ Relevant qualification verification
☐ Professional references where appropriate
☐ Additional lawful checks where relevant
☐ Conflict-of-interest declaration
☐ Security responsibilities
☐ Management approval
☐ Access restrictions
☐ MFA
☐ Privileged access monitoring
☐ Periodic access review

Example

A software developer with development access may require Level 2 or Level 3 screening.

The same person receiving unrestricted AWS production administrator access may require Level 3 or Level 4, depending on the organization’s risk assessment.

8. Financial Role Screening

For roles with significant financial responsibility:

Examples:

Finance Manager
Treasury
Payment Operations
Financial Controller
Certain regulated roles

Consider:

☐ Identity
☐ Employment
☐ Education/qualification
☐ Professional credentials
☐ References
☐ Conflict-of-interest declaration
☐ Financial checks where lawful and relevant
☐ Regulatory checks where applicable

Financial screening should not be applied merely because an employee works for the finance department.

9. Regulatory or Licensed Roles

Where the role requires regulatory authorization or professional licensing:

☐ License verified
☐ Registration verified
☐ Certification verified
☐ Regulatory status checked
☐ Expiry monitored
☐ Restrictions identified
☐ Required re-verification performed

Examples may include:

Regulated financial roles
Certified professionals
Security professionals requiring specific credentials
Legally regulated activities

10. Security Personnel

Security-sensitive roles may include:

Security Engineer
SOC Analyst
Security Architect
Cloud Security Engineer
Security Administrator
CISO
vCISO
VAPT personnel

Consider:

☐ Identity verification
☐ Employment verification
☐ Relevant education
☐ Security certifications
☐ Professional references
☐ Security experience
☐ Additional lawful checks where relevant
☐ Conflict-of-interest assessment
☐ Confidentiality requirements
☐ Privileged access requirements

11. VAPT and Security Testing Personnel

Personnel conducting security testing may receive sensitive information or temporary privileged access.

Before engagement:

☐ Identity verified
☐ Employer/organization verified
☐ Relevant qualifications verified
☐ Relevant experience verified
☐ References considered
☐ NDA/confidentiality requirements completed
☐ Scope authorized
☐ Access limited to testing requirements
☐ Temporary credentials used where practical
☐ Testing access expiry defined

12. Third-Party Personnel Matrix

The organization should also assess personnel provided by suppliers.

Third-Party Role	Access	Suggested Screening
General support	Internal	Level 1–2
Customer support	Customer information	Level 2
Developer	Source code	Level 2–3
Cloud engineer	Cloud infrastructure	Level 3–4
Security consultant	Security information	Level 3–4
VAPT tester	Security testing access	Level 3–4
Production administrator	Production systems	Level 4
Managed SOC analyst	Security monitoring	Level 3–4

Supplier contracts should define who is responsible for performing the required verification.

13. Intern Screening

For interns:

Access	Suggested Level
No sensitive systems	Level 1
Internal applications	Level 1–2
Development systems	Level 2
Source code	Level 2
Production systems	Generally restricted; if required, enhanced review

Interns should not automatically receive unrestricted production or privileged access simply because they have completed onboarding.

14. Remote Worker Screening

Remote work does not by itself require enhanced screening.

Consider enhanced requirements when the remote worker has:

Production access
Privileged access
Sensitive customer information
Security administration responsibilities
Financial authority
Access to restricted information

The screening requirement should be based on role and risk rather than physical work location alone.

15. Role Change Assessment

When an employee changes role:

Existing Role → New Role → Access Change → Risk Change → Screening Gap → Additional Verification

Example:

Developer → DevOps Engineer → AWS access → Higher privilege → Existing screening reviewed → Additional verification performed if required.

Record the assessment.

Employee	Existing Role	New Role	Risk Change	Additional Screening	Approval

16. Screening Override

A role may require a different screening level from the default matrix.

Examples:

Customer contract requires additional verification
Regulatory requirement applies
Privileged access is introduced
Security incident creates additional concern
Role responsibilities materially change

Any override should document:

Reason
Risk
Required screening
Approval
Expiry/review where applicable

17. Screening Exceptions

If required screening cannot be completed:

☐ Reason documented
☐ Risk assessed
☐ Missing checks identified
☐ Temporary controls established
☐ Access restricted where necessary
☐ Approval obtained
☐ Completion date established
☐ Exception tracked

Exceptions should be time-bound.

18. Screening Decision Matrix

Result	Action
All required checks satisfactory	Proceed
Minor discrepancy	Review and document
Material discrepancy	Additional review
Verification incomplete	Restrict/withhold applicable access
High-risk unresolved issue	Escalate to appropriate decision-maker
Unable to verify	Risk assessment and decision required
False positive identified	Investigate and resolve
Legal restriction on check	Use appropriate alternative assessment

The matrix supports consistent decisions but does not replace applicable employment, privacy, or other legal requirements.

19. Evidence Requirements

For each screening activity, retain appropriate evidence of:

☐ Requirement
☐ Authorization
☐ Check performed
☐ Date
☐ Source/provider
☐ Result
☐ Reviewer
☐ Decision
☐ Exception where applicable

Avoid retaining unnecessary copies of sensitive personal information.

20. Screening Register

ID	Personnel	Role	Risk	Level	Checks	Status	Reviewer	Date

The register should contain only the information necessary to manage the process.

21. Review of Screening Matrix

Review the matrix when:

☐ New roles are introduced
☐ New systems are introduced
☐ Privileged access changes
☐ New regulatory requirements apply
☐ Customer requirements change
☐ Security incidents indicate additional personnel risk
☐ Organizational structure changes
☐ Background verification provider changes
☐ Audit findings identify weaknesses
☐ Periodic review becomes due

22. Roles and Responsibilities

HR

Maintains:

Role screening requirements
Screening records
Verification status
Exceptions

Hiring Manager

Determines:

Role responsibilities
Information exposure
Access requirements
Business justification

Information Security

Reviews:

Security-sensitive roles
Privileged roles
Production access
High-risk screening requirements

Legal/Privacy

Advises on:

Lawfulness
Privacy
Sensitive checks
Jurisdictional requirements

Risk Owner

Approves significant personnel-related risk where required.

23. AWS SaaS Startup Example

Consider a SaaS startup operating primarily on AWS.

Role	AWS Access	Information	Risk	Screening
Marketing Executive	None	Internal	Low	Level 1
HR Executive	Limited SaaS	Employee information	Medium	Level 2
Developer	Dev AWS	Source code	Medium	Level 2–3
DevOps Engineer	Production	Infrastructure	High	Level 3
Security Engineer	Production/Security	Security information	High	Level 3–4
AWS Administrator	Privileged	Production	High/Critical	Level 4
VAPT Consultant	Temporary	Security data	High	Level 3–4

Example

An AWS administrator receives:

IAM administrative access
Production access
Security configuration access
Infrastructure access

The organization therefore assesses the role as high risk and applies the enhanced screening level defined by its matrix.

The screening decision is then connected to:

Role Risk → Screening → Approval → Access → Monitoring

24. Startup-Friendly Screening Model

A startup does not need a complex matrix with hundreds of job titles.

A practical approach is to classify roles into four groups.

Group 1 — General

Examples:

Marketing
Administration
General operations

Typical screening: Level 1

Group 2 — Standard

Examples:

HR
Sales
Customer support
Product
Developers without privileged access

Typical screening: Level 2

Group 3 — Sensitive

Examples:

Finance
Senior developers
DevOps
Security
Compliance
Source-code administrators

Typical screening: Level 3

Group 4 — Privileged/Critical

Examples:

AWS administrators
Production administrators
Security administrators
CISO/security leadership
Personnel managing critical infrastructure

Typical screening: Level 4

This approach can be expanded as the organization grows.

25. Common Mistakes

Avoid:

Applying identical checks to every employee
Making role title the only risk factor
Ignoring actual system access
Ignoring customer or contractual requirements
Granting privileged access before required screening
Performing sensitive checks without appropriate authorization
Treating the matrix as a substitute for legal review
Retaining unnecessary personal information
Failing to reassess screening when roles change
Allowing permanent exceptions without risk review
Using outdated role definitions
Forgetting third-party personnel

26. Relationship With Other ISMS Documents

Document	Relationship
Employee Screening Policy	Defines screening principles
Background Verification Procedure	Defines how verification is performed
Role-Based Screening Matrix	Defines screening by role/risk
Employee Onboarding Procedure	Uses screening completion during onboarding
Access Management Procedure	Controls access after authorization
Privileged Access Procedure	Controls high-risk access
Employee Offboarding Procedure	Removes access when personnel leave
Personnel Security Procedure	Defines personnel-security requirements
Security Awareness Procedure	Defines security training
Risk Assessment	Supports role-risk decisions
Information Security Exception Register	Records screening exceptions
Supplier Security Requirements	Covers third-party personnel

27. ISO/IEC 27001 Connection

A role-based screening matrix supports a risk-based approach to personnel security.

The organization should determine:

Which roles require screening
What level of screening is appropriate
Which checks are relevant
When verification must be completed
What evidence should be retained
How exceptions are handled
When re-verification is required

The Role-Based Screening Matrix is not itself a universally prescribed ISO/IEC 27001 document. The organization should determine the appropriate screening requirements based on its ISMS scope, risk assessment, applicable controls, legal requirements, contractual requirements, customer expectations, and role sensitivity.

28. Audit Evidence Checklist

An auditor may review:

☐ Employee Screening Policy
☐ Background Verification Procedure
☐ Role-Based Screening Matrix
☐ Role risk assessment
☐ Job descriptions
☐ Access requirements
☐ Sample screening records
☐ Screening register
☐ Verification results
☐ Exception records
☐ Approval records
☐ Privileged-user screening
☐ Contractor screening
☐ Third-party screening requirements
☐ Periodic matrix review
☐ Corrective actions

Sensitive personal information should not be unnecessarily disclosed as audit evidence.

29. Final Role-Based Screening Audit Trail

For each role, the organization should be able to demonstrate:

What does this person do?
What information can they access?
What systems can they access?
Do they have privileged access?
What is the risk of the role?
What screening level applies?
Which checks are required?
Were the checks completed?
Were discrepancies identified?
Who reviewed the results?
Was the role approved?
Does the screening requirement change if the role changes?

Final Principle

Role-based screening should connect personnel risk with actual responsibilities, information exposure, and system access. The objective is not maximum screening—it is appropriate, lawful, proportionate, and defensible screening for the risk presented by each role.