Screening Exception Form

1. Purpose

The Screening Exception Form is used when an approved personnel screening requirement cannot be completed, cannot be completed within the required timeframe, or requires a temporary deviation from the organization’s established screening requirements.

The form ensures that the exception is:

Clearly documented
Business justified
Risk assessed
Time-bound
Approved by an appropriate authority
Supported by compensating controls where necessary
Monitored until resolved
Formally closed

Core Principle

Identify Exception → Justify → Assess Risk → Define Controls → Approve → Monitor → Resolve → Close

2. Important Principle

A screening exception should not automatically mean that the screening requirement is cancelled.

The organization should determine whether:

The screening can be completed later
An alternative verification method is available
Access should be restricted temporarily
Compensating controls are required
The requirement can legally be deferred
The residual risk can be accepted

Exceptions should normally have a defined expiry or review date.

3. Exception Information

Field	Details
Exception ID
Date Raised
Personnel ID
Personnel Name/Reference
Employee / Contractor
Role
Department
Hiring/Business Owner
Screening Level
Exception Status
Requested Start Date
Exception Expiry Date
Reviewer

Status

☐ Draft
☐ Under Review
☐ Approved
☐ Approved With Conditions
☐ Rejected
☐ Expired
☐ Resolved
☐ Closed

4. Personnel and Role Information

Role: ______________________________

Employment Type:

☐ Employee
☐ Contractor
☐ Consultant
☐ Intern
☐ Temporary Worker
☐ Third-Party Personnel
☐ Other: __________________

Business Owner: ____________________

Manager: ___________________________

Engagement Start Date: ______________

Expected End Date: __________________

5. Role Risk Assessment

Role Risk

☐ Low
☐ Medium
☐ High
☐ Critical

Consider:

☐ Confidential information
☐ Restricted information
☐ Personal data
☐ Customer data
☐ Financial information
☐ Source code
☐ Production access
☐ Cloud access
☐ Privileged access
☐ Security administration
☐ Regulatory responsibility
☐ Critical business process

Risk Rationale

6. Screening Requirement

Identify the screening requirement that cannot currently be completed.

Required Screening Level

☐ Level 1 – Basic
☐ Level 2 – Standard
☐ Level 3 – Enhanced
☐ Level 4 – High Risk

Required Check

☐ Identity verification
☐ Address verification
☐ Employment verification
☐ Education/qualification verification
☐ Professional reference
☐ Professional certification/license
☐ Criminal-record check where lawful/relevant
☐ Financial check where lawful/relevant
☐ Sanctions/regulatory screening
☐ Right-to-work verification
☐ Conflict-of-interest declaration
☐ Other: ______________________________

7. Exception Description

Describe exactly what requirement cannot be completed.

Exception

Requirement That Cannot Be Met

Current Status

8. Reason for Exception

Select the applicable reason:

☐ Verification provider delay
☐ Information unavailable
☐ Third-party dependency
☐ Candidate/contractor documentation unavailable
☐ Jurisdictional limitation
☐ Legal restriction
☐ Technical issue
☐ Business urgency
☐ Emergency engagement
☐ International verification delay
☐ Role changed unexpectedly
☐ Other: ______________________________

Detailed Business Justification

9. Why Normal Screening Cannot Be Completed

Explain why the normal screening process cannot be followed.

Expected Resolution

10. Alternative Verification

Determine whether an alternative method can reduce the exception.

☐ Alternative identity verification
☐ Alternative employment verification
☐ Professional reference
☐ Certification verification
☐ Supplier attestation
☐ Previous screening evidence
☐ Additional management verification
☐ Other independent evidence
☐ No alternative available

Alternative Verification Performed

Result

11. Business Impact

If the screening requirement is not completed, assess the business impact.

Potential impacts:

☐ Hiring delay
☐ Project delay
☐ Customer commitment affected
☐ Critical skill unavailable
☐ Business continuity impact
☐ Security operations impact
☐ Production support impact
☐ Regulatory impact
☐ Other: ______________________________

Business Impact Assessment

12. Security Risk Assessment

Assess the security risk created by the exception.

Threat

Vulnerability

Exposure

Potential Impact

Risk

13. Risk Rating

Use the organization’s approved risk methodology.

Risk Factor	Rating
Likelihood
Impact
Inherent Risk
Existing Controls
Residual Risk

Residual Risk

☐ Low
☐ Medium
☐ High
☐ Critical

Risk Rationale

14. Access Impact

Determine whether the exception affects system or information access.

☐ No system access
☐ Internal application access
☐ Confidential information access
☐ Restricted information access
☐ Customer-data access
☐ Source-code access
☐ Cloud access
☐ Production access
☐ Privileged access
☐ Security administration access

Access Impact

15. Temporary Access Restrictions

Where appropriate, apply temporary restrictions.

☐ No privileged access
☐ No production access
☐ No customer-data access
☐ No restricted-information access
☐ Development access only
☐ Read-only access
☐ Limited application access
☐ Temporary account
☐ Time-limited access
☐ Additional approval required
☐ Enhanced monitoring

Access Restrictions

16. Compensating Controls

Identify controls that reduce the risk while the exception remains open.

Possible controls:

☐ Limited access
☐ Least privilege
☐ MFA
☐ Temporary account
☐ Expiring access
☐ Enhanced logging
☐ Additional management review
☐ Additional supervision
☐ Restricted production access
☐ Dual approval
☐ Additional reference verification
☐ Additional identity verification
☐ Increased access review frequency
☐ Additional security monitoring

Compensating Controls

Control	Owner	Start Date	Review Date	Status

17. Control Effectiveness

Assess whether the compensating controls adequately reduce the risk.

☐ Effective
☐ Partially Effective
☐ Not Effective
☐ Requires Additional Control

Assessment

18. Exception Duration

Exception Start Date: __________________

Exception Expiry Date: _________________

Expected Screening Completion Date: ______

Maximum Duration

Exceptions should not remain open indefinitely without formal review.

19. Remediation Plan

Define the action required to resolve the exception.

Action	Owner	Target Date	Evidence Required	Status

Completion Criteria

The exception may be closed when:

☐ Required screening completed
☐ Evidence reviewed
☐ Discrepancy resolved
☐ Temporary controls removed or updated
☐ Access restrictions reviewed
☐ Residual risk reassessed
☐ Closure approved

20. Screening Completion Tracking

Requirement	Status	Expected Date	Actual Date	Evidence

21. Legal and Privacy Review

Where applicable:

☐ Legal requirements reviewed
☐ Privacy requirements reviewed
☐ Screening limitation is legally permissible
☐ Alternative verification considered
☐ Personal-data handling reviewed
☐ International transfer requirements reviewed
☐ Regulatory requirements considered

Legal/Privacy Comments

22. Customer and Contractual Requirements

Determine whether the exception affects:

☐ Customer contract
☐ Security questionnaire commitment
☐ Data-processing requirement
☐ Regulatory commitment
☐ Supplier requirement
☐ Customer personnel-screening requirement
☐ Other contractual obligation

Impact

23. Third-Party Contractor Exception

If the exception applies to contractor or supplier personnel:

Supplier: ____________________________

Contract/Agreement: __________________

Supplier Screening Responsibility: _____

☐ Supplier notified
☐ Supplier approval obtained where required
☐ Supplier attestation obtained
☐ Contractual requirement reviewed
☐ Replacement personnel considered
☐ Access restrictions applied

Supplier Comments

24. Emergency Screening Exception

Emergency exceptions may be required when immediate personnel engagement is necessary.

Examples:

Critical incident
Business continuity event
Urgent production recovery
Critical skill requirement
Immediate security response

Before approving emergency access:

☐ Business emergency confirmed
☐ Risk assessed
☐ Minimum access defined
☐ MFA enabled
☐ Temporary access established
☐ Monitoring enabled
☐ Approval obtained
☐ Screening completion deadline established

Emergency Justification

25. Approval

Business Owner

Name: ______________________________

Role: _______________________________

Decision:

☐ Approve
☐ Approve With Conditions
☐ Reject

Comments:

Signature/Approval: __________________

Date: ______________________________

26. Information Security Approval

Required where the exception affects information-security risk or privileged access.

Reviewer: ___________________________

Risk Assessment Reviewed: ☐ Yes ☐ No

Compensating Controls Reviewed: ☐ Yes ☐ No

Decision:

☐ Approve
☐ Approve With Conditions
☐ Reject

Comments

Approval: ___________________________

Date: ______________________________

27. HR / People Approval

Reviewer: ___________________________

☐ Screening requirement reviewed
☐ Exception justified
☐ Verification plan established
☐ Retention/privacy requirements considered

Decision

☐ Approve
☐ Approve With Conditions
☐ Reject

Comments:

28. Legal / Privacy Approval

Required where the exception involves legal, privacy, regulatory, or jurisdictional restrictions.

Reviewer: ___________________________

☐ Legal implications reviewed
☐ Privacy implications reviewed
☐ Alternative process considered
☐ Exception is appropriately documented

Decision

☐ Approve
☐ Approve With Conditions
☐ Reject
☐ Not Required

Comments:

29. Risk Acceptance

Where residual risk exceeds the organization’s normal tolerance:

Risk Owner: _________________________

Residual Risk: _______________________

Risk Treatment:

☐ Reduce
☐ Avoid
☐ Share/Transfer
☐ Accept

Risk Acceptance Statement

Risk Owner Approval: ________________

Date: ______________________________

30. Exception Monitoring

While the exception remains open:

☐ Screening progress monitored
☐ Compensating controls monitored
☐ Access monitored
☐ Expiry date monitored
☐ Risk reassessed where necessary
☐ Status reported to owner
☐ Escalation triggered if overdue

Monitoring Frequency

☐ Weekly
☐ Monthly
☐ Quarterly
☐ Other: __________________

31. Exception Review

Review the exception when:

☐ Screening status changes
☐ Risk changes
☐ Role changes
☐ Access changes
☐ Compensating control fails
☐ Security incident occurs
☐ Contract changes
☐ Regulatory requirements change
☐ Exception approaches expiry

Review Record

Review Date	Reviewer	Risk	Status	Action

32. Exception Extension

Extensions should not occur automatically.

If an extension is required:

Original Expiry Date: __________________

New Expiry Date: ______________________

Reason for Extension:

Updated Risk Assessment: ☐ Completed

Updated Controls: ☐ Required ☐ Not Required

Approval: _____________________________

33. Exception Closure

The exception may be closed when the underlying screening requirement has been resolved or otherwise formally addressed.

☐ Required screening completed
☐ Verification evidence reviewed
☐ Outstanding discrepancy resolved
☐ Risk reassessed
☐ Compensating controls reviewed
☐ Temporary access restrictions reviewed
☐ Exception no longer required
☐ Register updated
☐ Closure approved

Closure Date

Closure Comments

34. Closure Approval

HR/People Owner: _____________________

Information Security: _________________

Risk Owner: __________________________

Business Owner: ______________________

Closure Date: _________________________

35. Expired Exception

If the exception reaches its expiry date without resolution:

☐ Escalate to owner
☐ Restrict applicable access
☐ Suspend access where appropriate
☐ Reassess risk
☐ Extend with approval
☐ Complete screening
☐ Convert to formal risk treatment/acceptance where appropriate

An expired exception should not simply remain open without review.

36. Screening Exception Register

Maintain a central register.

Exception ID	Personnel	Role	Risk	Requirement	Start	Expiry	Owner	Status

37. Exception Metrics

Useful management metrics include:

Metric	Result
Open screening exceptions
High-risk exceptions
Critical exceptions
Expired exceptions
Exceptions nearing expiry
Average exception duration
Exceptions by reason
Exceptions by department
Exceptions by employee/contractor type
Exceptions with access restrictions
Exceptions overdue for review
Exceptions successfully closed

38. Exception Trend Analysis

Review trends such as:

Repeated verification-provider delays
Frequent documentation gaps
Recurring exceptions for the same role
Excessive screening delays
Repeated access-before-screening requests
Contractor screening weaknesses
Jurisdiction-specific challenges

Recurring exceptions may indicate that the underlying screening process requires improvement.

39. Findings and Corrective Action

If exception analysis identifies a systemic weakness:

☐ Finding raised
☐ Root cause assessed
☐ Corrective action defined
☐ Process owner assigned
☐ Target date established
☐ Effectiveness review defined
☐ Management escalation completed where necessary

40. AWS SaaS Startup Example

A SaaS startup urgently needs an experienced AWS engineer to support a production incident.

The organization’s normal process requires enhanced screening before production administrative access.

Exception

The engineer’s employment and identity verification can be completed immediately, but one additional verification check is delayed because the external provider requires additional time.

Temporary Controls

☐ Identity verified
☐ Employment verified
☐ NDA completed
☐ AWS named account created
☐ MFA enabled
☐ Temporary privileged access
☐ Access limited to incident scope
☐ Session/activity logging enabled
☐ Access expiry defined
☐ Security owner assigned
☐ Outstanding verification tracked

Exception

Enhanced screening is temporarily incomplete due to verification-provider delay.

Risk Treatment

Restrict access to the minimum production resources required for incident recovery and require security-owner approval for privileged actions.

Closure

The exception is closed once the outstanding verification is completed, evidence is reviewed, and residual risk is reassessed.

Audit Trail

Emergency Need → Screening Gap → Risk Assessment → Temporary Controls → Approval → Limited Access → Verification Completion → Risk Reassessment → Closure

41. Startup-Friendly Exception Model

A startup can use a simple four-step process:

1. Identify

What screening requirement cannot be completed?

2. Assess

What risk does the delay create?

3. Control

Can access or responsibilities be restricted until screening is completed?

4. Approve and Track

Obtain the appropriate approval, define an expiry date, and track the exception to closure.

This prevents exceptions from becoming informal workarounds.

42. Common Mistakes

Avoid:

Treating an exception as permanent permission
Approving exceptions without risk assessment
Allowing unlimited privileged access during an exception
Failing to define an expiry date
Not assigning an owner
Not tracking outstanding screening
Repeatedly extending exceptions without addressing the root cause
Failing to document compensating controls
Ignoring privacy/legal requirements
Allowing expired exceptions to remain active
Using exceptions to bypass mandatory legal or regulatory requirements
Treating screening exceptions as routine administrative approvals

43. Relationship With Other ISMS Documents

Document	Relationship
Employee Screening Policy	Defines screening requirements
Background Verification Procedure	Defines verification activities
Role-Based Screening Matrix	Determines screening level
Employee Screening Checklist	Records completion of screening
Contractor Screening Procedure	Defines contractor screening
Access Management Procedure	Controls access during exceptions
Privileged Access Procedure	Controls privileged access
Risk Management Procedure	Assesses exception risk
Information Security Exception Register	Records the exception
Employee Onboarding Procedure	Controls onboarding dependencies
Supplier Security Requirements	Addresses supplier personnel
Incident Management Procedure	Handles security incidents

44. ISO/IEC 27001 Connection

A screening exception process supports risk-based management of personnel-security requirements.

The organization should ensure that exceptions are:

Identified
Justified
Risk assessed
Appropriately controlled
Approved by authorized personnel
Time-bound
Monitored
Reviewed
Resolved or formally risk-accepted

The Screening Exception Form is not itself a universally prescribed ISO/IEC 27001 document. The organization’s exception process should be aligned with its ISMS risk methodology, applicable controls, legal requirements, contractual requirements, and personnel-security requirements.

An internal screening exception should not be treated as authorization to disregard a mandatory legal or regulatory requirement.

45. Audit Evidence Checklist

Maintain appropriate evidence such as:

☐ Completed Screening Exception Form
☐ Screening requirement
☐ Role risk assessment
☐ Business justification
☐ Alternative verification assessment
☐ Risk assessment
☐ Compensating controls
☐ Access restrictions
☐ Approval records
☐ Risk acceptance where applicable
☐ Screening completion evidence
☐ Exception monitoring records
☐ Extension approvals
☐ Closure evidence
☐ Exception Register
☐ Corrective actions

Sensitive personal information should be minimized and protected.

46. Final Screening Exception Audit Trail

For every screening exception, the organization should be able to demonstrate:

What screening requirement could not be completed?
Why could it not be completed?
Why is the exception necessary?
What risk does the exception create?
What alternative verification was considered?
What compensating controls were implemented?
Who approved the exception?
When does the exception expire?
How is the exception monitored?
What happens if it is not resolved by the expiry date?
Was the required screening eventually completed?
Was residual risk reassessed?
Who approved closure?

Final Principle

A screening exception is a controlled, temporary deviation—not a permanent bypass of personnel-security requirements. Every exception should have a documented reason, risk assessment, appropriate controls, accountable owner, expiry/review date, and clear path to resolution or formal risk acceptance.