1. Purpose

The Contractor Account Procedure defines the process for requesting, approving, creating, managing, reviewing, modifying, and removing user accounts provided to contractors, consultants, freelancers, temporary personnel, and other external personnel.

The procedure ensures contractor access is:

• Based on a legitimate business need.
• Approved before provisioning.
• Limited to the minimum required access.
• Individually attributable where practical.
• Protected with appropriate authentication.
• Time-bound where appropriate.
• Periodically reviewed.
• Promptly removed when the engagement or business need ends.

Core Principle

Verify → Approve → Provision → Restrict → Monitor → Review → Revoke

---

2. Scope

This procedure applies to:

• Contractors
• Consultants
• Freelancers
• Temporary workers
• External specialists
• Outsourced personnel
• Vendor personnel
• Project-based personnel
• Third-party support personnel
• Other authorized external users

It covers access to:

• Corporate accounts
• Identity provider/SSO
• Email
• SaaS applications
• Cloud platforms
• AWS/Azure/GCP environments
• Source-code repositories
• Development environments
• Production systems
• Databases
• VPN/remote access
• Customer environments
• Security systems
• File-sharing platforms
• Collaboration tools
• Business applications
• Physical facilities where applicable

---

3. Definitions

Contractor Account

An account created for an external individual who requires authorized access to organizational systems or information.

Contractor Sponsor

The internal employee responsible for the contractor relationship and business justification for access.

System Owner

The person responsible for the system or application to which access is provided.

Access Owner

The person responsible for determining whether access to specific information or resources is appropriate.

Privileged Contractor

A contractor who receives administrative, elevated, production, security, cloud, database, or other high-risk access.

---

4. Contractor Account Lifecycle

The complete lifecycle is:

Contract/Business Need

↓

Contractor Verification

↓

Access Requirement

↓

Risk Assessment

↓

Approval

↓

Account Creation

↓

MFA/Authentication

↓

Access Provisioning

↓

Verification

↓

Monitoring

↓

Periodic Review

↓

Access Modification

↓

Contract/Engagement End

↓

Access Revocation

↓

Verification & Closure

---

5. Contractor Account Request

A contractor account should not be created without an approved request.

The request should include:

Field	Description
Request ID	Unique request number
Contractor Name	Individual’s name
Contractor Organization	Employer/vendor
Contractor Type	Consultant/Contractor/Freelancer/etc.
Internal Sponsor	Responsible employee
Manager	Sponsor’s manager where applicable
Business Purpose	Why access is required
Project	Relevant project
Systems Required	Applications/platforms
Environment	Production/Test/Development
Information Accessed	Type of information
Classification	Public/Internal/Confidential/Restricted
Access Level	Read/Write/Admin/etc.
Start Date	Required access date
End Date	Planned access end
Contract/SOW	Reference
NDA	Applicable status
Security Review	Required/Completed
Approval	Approver
Status	Pending/Approved/Rejected/Closed

---

6. Contractor Verification

Before account creation, the organization should verify the contractor’s identity and engagement.

Depending on organizational requirements, verification may include:

• Full name
• Contact information
• Contractor/vendor organization
• Contract/SOW
• Internal sponsor
• Engagement dates
• Role
• Business purpose
• Identity verification
• NDA/confidentiality requirements
• Security requirements
• Customer requirements
• Background verification where applicable

The organization should retain appropriate evidence without collecting unnecessary personal information.

---

7. Contract and NDA Verification

Before providing access, verify applicable contractual requirements.

Review, where relevant:

• NDA/confidentiality agreement
• Master Service Agreement
• Statement of Work
• Security requirements
• Data protection requirements
• Customer contractual requirements
• Incident notification obligations
• Data return/deletion requirements
• Subcontractor restrictions
• Access restrictions
• Security assessment requirements

If required contractual documentation is incomplete, access should not be provisioned until the issue is appropriately resolved or formally approved as an exception.

---

8. Access Requirement Assessment

The internal sponsor should identify exactly what the contractor needs.

Consider:

• Application
• System
• Environment
• Data
• Functions
• Required permissions
• Duration
• Location
• Remote access
• Production access
• Privileged access
• Customer access
• Confidential/Restricted information

Avoid requesting broad access such as:

“Full access to production.”

Instead specify:

“Read-only access to production application logs for the approved troubleshooting project from 1 October to 15 October.”

---

9. Risk Assessment

Contractor access should be assessed based on risk.

Risk factors may include:

• Production access
• Administrative privileges
• Customer data
• Personal data
• Financial information
• Source code
• Security information
• Restricted information
• Cloud administration
• Database access
• Remote access
• Third-party location
• Long-term access
• Subcontractor involvement
• Critical business systems

Higher-risk access may require additional approval or controls.

---

10. Access Categories

An organization may use categories such as:

Category	Example	Typical Controls
Low	Public/Internal information	Standard account controls
Moderate	Business applications	MFA, least privilege, review
High	Confidential/customer information	MFA, restricted access, monitoring, expiry
Critical	Production/privileged access	Explicit approval, MFA, monitoring, short duration, enhanced review

These categories are organizational examples and should be defined according to the organization’s risk methodology.

---

11. Contractor Account Approval

Approval should normally include:

Internal Sponsor

↓

System/Application Owner

↓

Data Owner/Security where required

↓

Authorized Approver

Approval should consider:

• Business need
• Contractor identity
• Contractual status
• Access scope
• Information classification
• Risk
• Duration
• Privilege level
• Required security controls

---

12. Account Creation

Once approved, IT/IAM or the designated system administrator creates the account.

The account should:

• Use the contractor’s identifiable identity.
• Be uniquely attributable where technically possible.
• Use the organization’s approved identity system.
• Have an appropriate username/account identifier.
• Be linked to the contractor record.
• Have an owner/sponsor.
• Have a defined start date.
• Have an expiry date where appropriate.
• Be configured with required authentication controls.
• Be documented in the appropriate register.

Avoid creating generic accounts such as:

contractor1

consultant-admin

unless there is a documented technical requirement and compensating accountability controls.

---

13. Authentication and MFA

Contractor accounts should use appropriate authentication controls.

Where supported:

• MFA should be enabled.
• SSO should be preferred.
• Strong authentication should be used.
• Password sharing should be prohibited.
• Authentication credentials should not be shared.
• Recovery methods should be controlled.
• Privileged access should have stronger controls where appropriate.

---

14. Access Provisioning

After account creation, provide only approved access.

The provisioning process should be:

Approved Request → Account → Authentication → Role → Permissions → Verification

Examples:

• SaaS application → specific role
• Git repository → required repository only
• AWS → specific IAM role
• Database → required database/schema
• VPN → approved network access
• Customer system → approved customer environment

---

15. AWS Contractor Access

For contractors requiring AWS access:

• Use an identifiable account/identity.
• Use SSO/IAM roles where practical.
• Require MFA.
• Avoid sharing administrator credentials.
• Restrict access to required AWS accounts.
• Restrict permissions to required resources.
• Separate development and production access.
• Use temporary access where practical.
• Enable appropriate logging.
• Set an expiry date for temporary engagements.

Example:

Contractor → SSO + MFA → Approved AWS Role → Specific Account/Resources → CloudTrail Logging

A contractor performing a short-term assessment should not automatically receive permanent administrator access.

---

16. Production Access

Production access should be separately evaluated.

Before granting production access, determine:

• Why production access is required.
• Which resources are required.
• Whether read-only access is sufficient.
• Duration of access.
• Whether privileged access is required.
• Monitoring requirements.
• Approval requirements.
• Customer/contractual restrictions.

Where possible, production access should be temporary and removed immediately after the approved task is completed.

---

17. Privileged Contractor Access

Privileged contractor access may include:

• Cloud administrator
• Database administrator
• Security administrator
• Network administrator
• Production administrator
• Source-code administrator
• CI/CD administrator

For privileged access:

• Document the business justification.
• Obtain explicit approval.
• Use named identities.
• Require strong authentication/MFA.
• Apply least privilege.
• Limit duration.
• Monitor activity where technically feasible.
• Record the access in the Privileged Access Register where applicable.
• Review after use.
• Revoke promptly when no longer required.

---

18. Temporary Access

Where access is required only for a defined period, configure an expiry date.

Example:

Contractor requires production read-only access from 1 October to 7 October for incident investigation.

At expiry:

Access Expires → Verify → Revoke → Record

Temporary access should not become permanent simply because nobody remembered to remove it.

---

19. Contractor Access to Customer Systems

If contractors access customer environments:

• Confirm customer authorization where required.
• Confirm contractual requirements.
• Identify the customer environment.
• Define access scope.
• Use named accounts where possible.
• Apply MFA.
• Restrict permissions.
• Monitor access where appropriate.
• Define duration.
• Revoke access when the work ends.
• Retain appropriate evidence.

---

20. Contractor Access to Confidential or Restricted Information

Before granting access, determine:

• What information is involved.
• Why access is required.
• Whether access can be minimized.
• Whether the contractor is authorized.
• Whether contractual protections exist.
• Whether secure transfer/storage is required.
• Whether access should expire.
• Whether additional monitoring is necessary.

Restricted information should receive stronger access controls than routine internal information.

---

21. Source-Code Access

Contractors requiring source-code access should receive only the repositories and permissions required.

Controls may include:

• Named account
• MFA
• Repository-specific access
• Branch restrictions
• Pull-request/code-review requirements
• No unnecessary repository access
• Monitoring
• Access expiry
• Credential protection
• Removal when engagement ends

Contractors should not automatically receive organization-wide repository access.

---

22. SaaS Application Access

For contractor access to SaaS applications:

• Identify the application.
• Assign an internal owner.
• Define required role.
• Apply MFA/SSO.
• Limit access to required information.
• Set expiry where possible.
• Review periodically.
• Remove access at engagement end.

The SaaS Application Register should be updated where the contractor relationship materially affects application access or risk.

---

23. Contractor Access Review

Contractor accounts should be reviewed periodically.

The review should verify:

• Contractor is still engaged.
• Sponsor is still valid.
• Business purpose remains valid.
• Access remains necessary.
• Permissions remain appropriate.
• Privileged access remains justified.
• MFA remains enabled where required.
• Account is not dormant.
• Expiry date is appropriate.
• Customer/system restrictions remain satisfied.

Possible outcomes:

Retain → Modify → Reduce → Suspend → Revoke

---

24. Contractor Role Change

If the contractor’s role or project changes:

Role Change → Review Existing Access → Remove Unnecessary Access → Request New Access → Approve → Provision → Verify

Do not simply add new permissions while leaving old permissions active.

This prevents privilege accumulation.

---

25. Contractor Offboarding

When the contractor’s engagement ends:

1. Receive termination/end-of-engagement notification.
2. Identify all accounts and access.
3. Disable/revoke accounts.
4. Revoke privileged access.
5. Revoke VPN/remote access.
6. Remove SaaS access.
7. Remove cloud access.
8. Remove source-code access.
9. Revoke API tokens/SSH keys/certificates where applicable.
10. Recover organizational assets.
11. Recover or transfer organizational information.
12. Confirm data return/deletion requirements.
13. Remove physical access.
14. Update identity/access registers.
15. Verify revocation.
16. Record evidence.
17. Close the offboarding activity.

---

26. Emergency Contractor Access Revocation

Immediate revocation may be required when:

• Contractor engagement is terminated unexpectedly.
• Credentials are compromised.
• Unauthorized activity is identified.
• Contractor violates security requirements.
• Security incident involves the account.
• Customer requires immediate removal.
• Contractor no longer has a business need.

Process:

Trigger → Identify Access → Disable Account → Revoke Sessions/Tokens → Revoke Privileges → Verify → Investigate if Required → Record

---

27. Contractor Asset Return

Account revocation should be coordinated with asset management.

Assets may include:

• Laptop
• Mobile
• Security key
• Access card
• USB/media
• Documents
• Equipment
• Customer equipment
• Other organizational property

Returning an asset does not automatically revoke digital access.

Both activities must be completed separately.

---

28. Contractor Information Handover

Before closure, identify information held by the contractor.

This may include:

• Project documentation
• Customer information
• Source code
• Credentials/secrets
• Security reports
• Audit evidence
• Business documents
• Configuration information
• Tickets
• Technical documentation

Information should be returned, transferred, or securely deleted according to contractual and organizational requirements.

---

29. Service and API Credentials

Contractor-related credentials may include:

• API keys
• SSH keys
• Access tokens
• Certificates
• Cloud credentials
• VPN credentials
• Application credentials

At offboarding, identify and revoke credentials that are:

• Personally assigned
• Controlled by the contractor
• Known to the contractor
• Associated with contractor automation
• Associated with contractor integrations

Credential rotation may also be required where a credential was shared or potentially exposed.

---

30. Contractor Account Register

Maintain a record of contractor accounts.

Recommended fields:

Field	Description
Account ID	Unique account
Contractor Name	Individual
Organization	Vendor/employer
Sponsor	Internal sponsor
Role	Contractor role
Purpose	Business purpose
System	Application/system
Environment	Prod/Test/Dev
Access Level	Permissions
Privileged	Yes/No
MFA	Yes/No
Start Date	Access start
Expiry Date	Access end
Last Review	Review date
Status	Active/Disabled/Closed
Related Request	Request ID
Contract/SOW	Reference
Evidence	Evidence location

---

31. Contractor Account Closure Record

Field	Details
Contractor
Account
Engagement End Date
Account Disabled
Privileged Access Revoked
VPN Revoked
SaaS Access Removed
Cloud Access Removed
Source Code Access Removed
Tokens/Keys Revoked
Assets Returned
Information Returned/Deleted
Physical Access Removed
Verification Completed
Verified By
Closure Date
Exceptions

---

32. Exceptions

Exceptions may include:

• Access without expiry because of technical limitations.
• Legacy application restrictions.
• Shared technical account.
• Extended contractor access.
• Privileged access required for critical support.
• Customer-mandated access arrangements.

Each exception should document:

Field	Description
Exception ID	Unique ID
Contractor	Individual
Account	Account
Exception	What is different
Reason	Business/technical reason
Risk	Associated risk
Compensating Control	Additional protection
Owner	Responsible person
Approval	Authorized approval
Expiry/Review	Review date
Status	Open/Closed

---

33. Audit Evidence

Typical evidence includes:

• Contractor account requests
• Approval records
• Contracts/SOWs
• NDA records
• Identity verification
• Access provisioning records
• IAM/SSO records
• MFA configuration
• Access-control records
• AWS IAM/SSO records
• Privileged Access Register
• Access Review Reports
• Contractor Account Register
• Access Revocation records
• Offboarding checklist
• Asset Return records
• Credential revocation records
• Data return/deletion evidence
• Exception records
• Relevant logs

---

34. Roles and Responsibilities

Role	Responsibility
Internal Sponsor	Business justification and contractor relationship
Manager	Validate business need
System Owner	Approve system access
Data Owner	Approve sensitive information access
IT/IAM	Create, modify and disable accounts
Security/ISMS	Risk/security oversight
HR/Procurement	Contract and engagement information
Contractor	Protect credentials and information
Asset Owner	Manage organizational assets
Internal Audit	Independently verify effectiveness

---

35. AWS SaaS Startup Example

A SaaS startup engages an external DevOps contractor for a two-week infrastructure project.

Requirement

The contractor needs:

• AWS development access
• Git repository access
• CI/CD access
• No permanent production administrator access

Process

Contract/SOW

↓

Contractor Verification

↓

Access Request

↓

Risk Assessment

↓

Approval

↓

SSO + MFA

↓

Limited AWS Role

↓

Repository-Specific Access

↓

Two-Week Expiry

↓

Monitoring

↓

Project Completion

↓

Access Revocation

↓

Verification

The contractor’s AWS and repository access should then be checked to confirm that access was actually removed.

---

36. Startup-Friendly Minimum Process

For a small organization, the process can remain simple:

Before Access

Verify Contractor → Confirm Contract → Define Access → Approve → Create Account → MFA → Record

During Engagement

Least Privilege → Monitor → Review → Modify When Needed

At End

Disable → Revoke → Recover Assets → Transfer/Delete Information → Verify → Record

This provides a practical control structure without requiring a large IAM platform.

---

37. Common Mistakes

Avoid:

• Creating accounts without an internal sponsor.
• Using shared contractor accounts.
• Giving contractors permanent access.
• Giving production access by default.
• Granting administrator privileges unnecessarily.
• Forgetting contractor accounts during offboarding.
• Removing email but leaving cloud access.
• Returning the laptop but leaving digital access active.
• Leaving old project permissions after role changes.
• Storing contractor passwords or API keys in spreadsheets.
• Failing to review third-party access.
• Not recording access expiry.
• Not verifying that revocation actually occurred.

---

38. Relationship with Other ISMS Documents

The Contractor Account Procedure should work together with:

• Identity Management Policy
• User Account Management Procedure
• Joiner-Mover-Leaver Procedure
• Contractor Offboarding Checklist
• Third-Party Access Procedure
• Access Control Policy
• Access Control Matrix
• Privileged Access Register
• Identity Register
• Access Review Report
• Access Revocation Checklist
• Asset Return Checklist
• Information Classification Policy
• Data Handling Guidelines
• Third-Party Information Sharing Agreement
• Supplier Security Assessment
• Incident Management Procedure
• Risk Assessment Procedure

Control Relationship

Contractor

→ Identity Verification

→ Contract/SOW

→ Access Request

→ Risk Assessment

→ Approval

→ Account Creation

→ Least Privilege

→ Monitoring

→ Access Review

→ Offboarding

→ Revocation

→ Evidence

---

39. ISO 27001 Connection

The procedure supports the organization’s implementation of applicable ISO/IEC 27001 information-security controls relating to:

• Identity management
• Authentication
• Access rights
• Privileged access
• Access restriction
• Segregation of duties
• Supplier relationships
• Information classification
• Secure information transfer
• Return of assets
• Event/incident management
• Logging and monitoring

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

---

40. Quick Audit Checklist

Before Access

• Contractor verified
• Internal sponsor assigned
• Contract/SOW confirmed
• NDA/confidentiality requirements checked
• Business purpose documented
• Required systems identified
• Information classification assessed
• Risk assessed where appropriate
• Access approved
• Expiry defined where appropriate

During Access

• Unique account provided
• MFA enabled where required
• Least privilege applied
• Production access separately approved
• Privileged access separately controlled
• Activity monitored where appropriate
• Access reviewed periodically

At Offboarding

• Account disabled
• Sessions revoked
• Privileged access revoked
• Cloud access revoked
• SaaS access removed
• Source-code access removed
• VPN access removed
• API keys/tokens/certificates addressed
• Assets returned
• Information returned/transferred/deleted as required
• Physical access removed
• Revocation verified
• Registers updated
• Evidence retained

---

41. Final Audit Trail

For every contractor account, the organization should be able to demonstrate:

Who is the contractor?

→ Why do they need access?

→ Who approved it?

→ What can they access?

→ Why is that level of access required?

→ How is the account protected?

→ When was it reviewed?

→ When does access expire?

→ What happened when the engagement ended?

→ Was access actually revoked?

→ Is evidence available?

Final Principle

Contractor access should be temporary where practical, individually attributable, explicitly authorized, limited to business need, appropriately protected and monitored, regularly reviewed, and completely revoked when the engagement or business need ends.