Third-Party Access Procedure

1. Purpose

The Third-Party Access Procedure defines how access provided to suppliers, consultants, contractors, auditors, partners, service providers, and other external parties is requested, assessed, approved, provisioned, monitored, reviewed, and revoked.

The objective is to ensure third-party access is:

Business justified
Authorized
Limited to the required systems and information
Based on least privilege
Time-bound where practical
Individually attributable
Securely authenticated
Monitored where appropriate
Periodically reviewed
Removed when no longer required

Core Principle

Business Need → Assess → Approve → Provision → Monitor → Review → Revoke

2. Scope

This procedure applies to external parties requiring access to:

Corporate systems
SaaS applications
AWS/Azure/GCP environments
Production systems
Development/test environments
Databases
Source-code repositories
Customer systems
File-sharing platforms
Security tools
VPN/remote-access systems
Physical facilities
Confidential or Restricted information

Examples of third parties include:

Consultants
Contractors
Auditors
Certification bodies
VAPT providers
Managed service providers
Cloud consultants
Software vendors
Customer representatives
Implementation partners
Outsourced service providers
Supplier personnel

3. Third-Party Access Principles

Third-party access should follow these principles:

Business Need – access must have a defined purpose.
Least Privilege – provide only required permissions.
Need-to-Know – restrict information access.
Named Accounts – avoid shared accounts.
Strong Authentication – MFA where appropriate.
Time Limitation – define an expiry date where practical.
Approval – appropriate owners approve access.
Monitoring – monitor high-risk activity where appropriate.
Review – periodically confirm continued need.
Revocation – remove access when the need ends.
Evidence – retain records of authorization and actions.

4. Third-Party Access Lifecycle

The complete lifecycle is:

Business Need

↓

Access Request

↓

Third-Party Verification

↓

Security/Risk Assessment

↓

Contract/NDA Review

↓

Access Scope Definition

↓

Approval

↓

Provision Access

↓

Verify

↓

Monitor

↓

Periodic Review

↓

Revoke

↓

Close & Record

5. Third-Party Access Request

Every request should record:

Field	Details
Request ID	Unique ID
Third Party	Organization/person
Individual User	Named external user
Role	Consultant/Auditor/etc.
Internal Sponsor	Internal owner
Business Purpose	Why access is required
System	System/application
Environment	Production/Test/Development
Information	Information accessed
Classification	Public/Internal/Confidential/Restricted
Access Level	Read/Write/Admin/etc.
Start Date	Access commencement
Expiry Date	Access end
Contract/SOW	Reference
NDA	Applicable status
Approver	Authorized approver
System Owner	System owner
Security Approval	Where required
Status	Requested/Approved/Active/Closed

6. Verify the Third Party

Before granting access, confirm:

Third-party organization
Individual’s identity
Role
Business relationship
Internal sponsor
Contract/SOW
NDA/confidentiality requirements
Purpose of access
Required duration
Systems involved
Information involved

For higher-risk access, additional supplier/security due diligence may be appropriate.

7. Contract and Agreement Review

Before granting access to sensitive information or systems, verify applicable contractual requirements.

Consider:

NDA
Master Service Agreement
Statement of Work
Data Processing Agreement
Security requirements
Confidentiality obligations
Incident notification requirements
Data protection requirements
Subcontractor requirements
Data return/deletion requirements
Access restrictions
Audit/assurance requirements

Access should not be granted merely because a commercial relationship exists.

8. Security Risk Assessment

Assess the risk associated with the requested access.

Consider:

Information classification
System criticality
Production access
Privileged access
Customer information
Personal data
Financial information
Source code
Security information
Credentials/secrets
Internet exposure
Duration of access
Third-party location
Remote access
Subcontractors
Business impact

Higher-risk access should receive additional review and stronger controls.

9. Access Classification

Classify third-party access based on risk.

Access Type	Example	Typical Control
Low	Public/Internal information	Standard authenticated access
Moderate	Confidential business information	Named account + controlled access
High	Customer data / production systems	Strong approval + MFA + monitoring
Critical	Privileged production/cloud access	Explicit approval + strong controls + close monitoring/review

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

10. Define Access Scope

Clearly identify:

Systems

Application
Cloud account
Database
Repository
SaaS platform

Environment

Development
Test
Staging
Production

Resources

Specific project
Specific database
Specific repository
Specific AWS account/resource
Specific customer environment

Permissions

Read
Create
Update
Delete
Export
Configure
Administer

Avoid:

“Full access to the system.”

unless full access is genuinely necessary and formally approved.

11. Third-Party Access Approval

Typical approval flow:

Internal Sponsor → System Owner → Data Owner/Security → Authorized Approver

Approval should consider:

Business justification
Scope
Data classification
Risk
Duration
Permissions
Contractual requirements
Security controls

Privileged or production access should receive additional approval where required.

12. Account Provisioning

Once approved:

Create an individual account.
Do not share employee accounts.
Apply approved role.
Apply least privilege.
Enable MFA where required.
Configure expiry where practical.
Restrict network access where appropriate.
Enable logging where required.
Document the account.

Third-party accounts should normally be identifiable to a specific individual.

13. Third-Party Access to AWS

For AWS access:

Use individual identities.
Prefer centralized identity/SSO where appropriate.
Use IAM roles with limited permissions.
Enable MFA.
Avoid sharing administrator credentials.
Limit access to required accounts/resources.
Use temporary credentials where practical.
Log administrative activity.
Review access periodically.
Remove access when the engagement ends.

Example

A cloud consultant requires access to troubleshoot a production configuration.

Instead of:

Permanent AWS Administrator access

provide, where technically appropriate:

Named consultant identity → MFA → Limited IAM role → Required production resources → Defined expiry → Logging

14. Third-Party Production Access

Production access should be treated as higher risk.

Before granting:

Business justification
System owner approval
Security review where required
Contractual authorization
Named user
MFA
Least privilege
Defined duration
Logging
Monitoring where appropriate
Review/expiry date

15. Third-Party Privileged Access

Privileged third-party access may include:

Cloud administration
Database administration
Security administration
Network administration
Source-code administration
Identity administration
Production administration

For privileged access:

Specific business need
Explicit approval
Named account
MFA
Limited permissions
Defined duration
Logging
Monitoring where appropriate
Privileged Access Register entry
Periodic review
Immediate revocation when no longer required

16. Third-Party Access to Customer Information

Before providing customer information:

Confirm contractual authorization.
Identify the exact information.
Confirm classification.
Minimize information.
Verify the recipient.
Check privacy requirements where applicable.
Use an approved transfer/access mechanism.
Define retention/deletion requirements.
Record the access.

17. Third-Party Source-Code Access

For consultants or suppliers requiring source-code access:

Approved repository
Named account
Specific repository/project
Least privilege
MFA
Branch protections maintained
No unnecessary repository administrator access
Secrets excluded
Access expiry configured
Activity logged where appropriate

18. Third-Party Database Access

Direct database access should be carefully controlled.

Consider:

Read-only access where possible
Specific database/schema
Production vs test
Restricted network access
MFA/strong authentication
Logging
Temporary access
Query monitoring where appropriate
Data minimization
Access expiry

19. Third-Party Remote Access

Remote access should use approved mechanisms.

Examples:

VPN
Zero-trust access
SSO
Secure remote-access gateway
Bastion/jump host
Approved cloud access

Do not provide unrestricted remote network access when a narrower mechanism can satisfy the business requirement.

20. Temporary Third-Party Access

Temporary access should include:

Start date
End date
Purpose
System
Permission level
Approver
Owner
Expiry

Example

A VAPT provider requires AWS access from:

10 October → 15 October

Access should be configured to expire at the end of the approved period where technically possible.

21. Access Monitoring

Depending on risk, monitor:

Login activity
Privilege changes
Administrative activity
File access
Database activity
Cloud activity
Configuration changes
Source-code activity
Data downloads
Authentication failures

High-risk third-party activity should receive appropriate monitoring.

22. Periodic Access Review

Review third-party access based on risk and engagement requirements.

Check:

Third party relationship remains active
Individual is still engaged
Business purpose remains valid
System access remains necessary
Permissions remain appropriate
Production access remains justified
Privileged access remains justified
MFA remains enabled
Expiry date remains appropriate
Contract/SOW remains valid

23. Third-Party Access Review Record

Third Party	User	System	Current Access	Required?	Action	Owner	Review Date	Status
Cloud Consultant	User A	AWS	Admin	Yes	Retain with controls	CTO	Date	Active
Auditor	User B	Audit Repository	Read	Yes	Retain	ISMS	Date	Active
Former Consultant	User C	GitHub	Write	No	Revoke	Engineering	Date	Closed

24. Third-Party Access Revocation

Access must be revoked when:

Contract ends
SOW ends
Project ends
Individual leaves supplier
Business need ends
Temporary access expires
Supplier relationship terminates
Security incident requires immediate restriction

Review:

SSO
SaaS
AWS/cloud
VPN
Source code
Database
Customer systems
API keys
SSH keys
Tokens
Certificates
Physical access

25. Third-Party Offboarding

Use the following process:

Engagement End → Identify Access → Disable Accounts → Revoke Privileges → Revoke Tokens/Keys → Recover Information → Collect Assets → Confirm Data Return/Deletion → Verify → Update Registers → Close

Where contractually or legally required, obtain appropriate confirmation of information return or deletion.

26. Subcontractor Access

If a supplier uses subcontractors:

Identify subcontractors where required.
Determine whether subcontractor access is permitted.
Assess security requirements.
Confirm contractual authorization.
Apply equivalent security requirements where appropriate.
Identify individual users.
Limit access.
Review periodically.
Revoke when no longer required.

A supplier should not automatically be allowed to provide organizational information or access to an unknown downstream party.

27. Shared Accounts

Third-party shared accounts should generally be avoided.

If technically unavoidable:

Document justification.
Identify accountable owner.
Protect credentials securely.
Restrict access.
Monitor activity where possible.
Change credentials when personnel change.
Review regularly.

28. Third-Party Access Exceptions

Exception ID	Third Party	System	Exception	Reason	Risk	Compensating Control	Approver	Expiry	Status
TPA-001	Supplier	AWS	Temporary Admin	Emergency remediation	High	MFA + logging	CTO	Date	Closed

Exceptions should be:

Business justified
Risk assessed
Approved
Time-bound where practical
Monitored
Closed when no longer required

29. Security Incident Involving Third-Party Access

Examples:

Compromised supplier account
Suspicious third-party login
Unauthorized data access
Exposed third-party credential
Unauthorized privilege escalation
Lost third-party device
Supplier employee accessing systems outside approved scope

Response may include:

Disable Access → Revoke Sessions → Rotate Credentials → Preserve Evidence → Investigate → Assess Impact → Notify Relevant Parties → Remediate → Review

Follow the organization’s Incident Response and Data Breach Response procedures where applicable.

30. Third-Party Access Register

Maintain a dedicated register where useful.

ID	Third Party	User	System	Role	Access Level	Data	Purpose	Start	Expiry	Approver	MFA	Review	Status
TPA-001
TPA-002
TPA-003

31. Evidence

Maintain appropriate evidence such as:

Third-Party Access Request
Contract/SOW
NDA
DPA where applicable
Security assessment
Risk assessment
Access approval
IAM configuration
MFA evidence
Access logs
Privileged Access Register
Access review records
Temporary access records
Access revocation evidence
Data return/deletion confirmation where applicable
Exception records
Incident records

32. Common Mistakes

❌ Giving suppliers permanent access

Access should normally have a defined lifecycle.

❌ Using employee accounts for contractors

External users should normally have individually attributable accounts.

❌ Giving full administrator access

Grant only the permissions required.

❌ Forgetting third-party access after project completion

Project closure should trigger an access review.

❌ Ignoring subcontractors

Downstream access should be considered.

❌ No expiry date

Temporary access should have an appropriate expiry.

❌ No monitoring for high-risk access

Production and privileged third-party activity may require enhanced monitoring.

❌ Contract exists, therefore access is automatically acceptable

A commercial relationship does not by itself define the required security permissions.

33. Startup-Friendly Implementation

A startup can implement a simple workflow:

Step 1 — Identify

Who is the third party?

Step 2 — Define

What exactly do they need?

Step 3 — Assess

What information and systems are involved?

Step 4 — Approve

Manager/System Owner/Security as appropriate.

Step 5 — Provision

Named account + least privilege + MFA.

Step 6 — Monitor

Log and monitor higher-risk activity.

Step 7 — Review

Confirm continued need.

Step 8 — Revoke

Remove access when the work ends.

Step 9 — Evidence

Retain approval, access, review, and revocation records.

34. Example – External VAPT Provider

A SaaS company hires an external VAPT provider.

Requirement

The provider needs to test:

Web application
APIs
Selected cloud resources

Process

Business Requirement

↓

VAPT Scope

↓

Supplier Verification

↓

NDA/SOW

↓

Risk Assessment

↓

Access Request

↓

Security/CTO Approval

↓

Named Account + MFA

↓

Limited Testing Access

↓

Logging/Monitoring

↓

VAPT

↓

Access Revocation

↓

Evidence

The provider should not automatically receive unrestricted production administrator access simply because they are performing a security assessment.

35. Relationship with Other ISMS Documents

The Third-Party Access Procedure connects with:

Supplier Security Policy
Supplier Security Assessment
Third-Party Information Sharing Agreement
External Data Sharing Procedure
Access Control Policy
Access Control Matrix
User Access Request
User Access Review Checklist
Privileged Access Register
Access Revocation Checklist
Contractor Offboarding Checklist
Information Classification Policy
Data Handling Guidelines
Cloud Asset Inventory
SaaS Application Register
Incident Response Plan
Data Breach Response Procedure
Risk Register

Complete Lifecycle

Supplier → Business Need → Risk Assessment → Contract → Access Request → Approval → Provision → Monitor → Review → Revoke

36. ISO 27001 Connection

The Third-Party Access Procedure supports applicable ISO/IEC 27001 requirements relating to:

Access control
Identity management
Authentication
Access rights
Privileged access
Information classification
Supplier relationships
Information transfer
Monitoring
Incident management
Access removal

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

37. Final Audit Trail

An auditor should be able to trace:

Who is the third party?

↓

Why do they need access?

↓

What information/system do they access?

↓

What permissions were granted?

↓

Who approved the access?

↓

What security controls were applied?

↓

Was access reviewed?

↓

When was it revoked?

↓

Was revocation verified?

Final Principle

Third-party access should be treated as a controlled lifecycle, not a one-time permission. Give external parties only the access they need, for the period they need it, protect and monitor that access according to risk, review it regularly, and revoke it when the business need ends.

ISO/IEC 27001