What is ISO 27001 Annex A 6.5?
ISO 27001 Annex A 6.5 requires the organization to ensure that information security responsibilities and duties that remain valid after termination or change of employment are defined, enforced, and communicated to relevant personnel.
In simple terms, security responsibilities should not simply disappear when:
- An employee leaves the organization.
- An employee changes departments.
- An employee moves to a different role.
- A contractor’s engagement ends.
- A person loses privileged responsibilities.
Some responsibilities may continue after the employment relationship ends, while others need to change when the person’s role changes.
Simple explanation
When someone leaves or changes roles, their security responsibilities and access must change appropriately—and obligations that continue after departure must remain clear.
Why is Annex A 6.5 Important?
Employees and contractors may have access to:
- Customer information.
- Source code.
- Cloud environments.
- Production systems.
- Security tools.
- Credentials.
- Intellectual property.
- Confidential documents.
- Business information.
When someone leaves, their access may become an immediate security risk if it is not removed promptly.
When someone changes roles, the opposite problem can occur:
A person may retain access that was appropriate for their old position but is no longer required.
For example:
A developer becomes a sales employee but still has access to:
- Production databases.
- Git repositories.
- Cloud administration.
- Security monitoring.
That creates unnecessary privilege.
Security Risks Addressed by A.6.5
A good termination and role-change process helps reduce:
- Unauthorized access after termination.
- Former employee access to cloud systems.
- Retention of company credentials.
- Unauthorized copying of information.
- Continued access to customer information.
- Excessive privileges after role changes.
- Unreturned company assets.
- Unauthorized use of company accounts.
- Disclosure of confidential information.
- Failure to communicate continuing obligations.
Simple principle
When someone’s employment or role changes, their access and security responsibilities should change with it.
What Does Annex A 6.5 Require?
The organization should define and communicate information security responsibilities that:
- Continue after employment termination.
- Continue after a change of role.
- Need to be removed or modified.
- Apply to contractors and other relevant personnel.
The organization should also ensure that appropriate responsibilities are:
- Defined.
- Communicated.
- Enforced.
- Reflected in contracts or agreements where appropriate.
- Connected to the organization’s offboarding and access-management processes.
What Responsibilities Can Continue After Employment?
Depending on applicable law, contracts and organizational requirements, continuing responsibilities may include:
Confidentiality
Employees may continue to have confidentiality obligations concerning:
- Trade secrets.
- Customer information.
- Source code.
- Business plans.
- Security information.
- Proprietary information.
Intellectual Property
Relevant obligations concerning company intellectual property may continue according to applicable agreements and law.
Information Protection
Former employees may remain obligated not to improperly disclose or use protected organizational information.
Return or Deletion of Information
Personnel may be required to return or appropriately delete organizational information and assets according to established procedures.
Non-Disclosure Agreements
Where applicable, confidentiality or non-disclosure agreements may contain continuing obligations.
The exact legal effect of these obligations depends on the applicable contract and jurisdiction.
Responsibilities After a Change of Employment
A.6.5 is not only about people leaving.
It also applies when an employee changes roles.
Examples:
- Developer → Sales.
- IT Administrator → Project Manager.
- HR → Finance.
- Support → Engineering.
- Security Administrator → General IT role.
- Manager → Individual contributor.
A role change should trigger a review of:
- Access rights.
- Privileged access.
- Group memberships.
- System permissions.
- Security responsibilities.
- Training requirements.
- Confidentiality requirements.
- Physical access.
Termination vs. Role Change
These situations require different actions.
Termination
Typical actions include:
- Disable accounts.
- Revoke access.
- Remove group memberships.
- Revoke privileged access.
- Recover company assets.
- Recover authentication devices.
- Handle tokens/credentials.
- Transfer business ownership.
- Protect organizational information.
- Communicate continuing obligations.
Role Change
Typical actions include:
- Review existing access.
- Remove unnecessary permissions.
- Add new permissions.
- Remove old group memberships.
- Change privileged access.
- Update responsibilities.
- Provide additional training.
- Update system ownership where required.
Activities Required to Implement A.6.5
Step 1 — Define Termination Responsibilities
Create a documented offboarding process.
It should identify:
- HR responsibility.
- Manager responsibility.
- IT responsibility.
- Information Security responsibility.
- Asset-management responsibility.
- Payroll/finance responsibility where relevant.
- Legal responsibility where applicable.
Step 2 — Define the Trigger
The process should be triggered by events such as:
- Resignation.
- Termination.
- Contract expiry.
- End of internship.
- End of contractor engagement.
- Role change.
- Department transfer.
- Extended leave where access needs review.
- Change in privileged responsibilities.
Step 3 — Review Access
Before or at the effective time of termination, as appropriate, review:
- Email.
- VPN.
- SSO.
- Cloud platforms.
- SaaS applications.
- Source-code repositories.
- Production systems.
- Databases.
- Security tools.
- Ticketing systems.
- Collaboration platforms.
- Physical access.
For a role change, determine:
What access is no longer required?
and
What new access is required?
Step 4 — Disable or Modify Access
For terminated personnel, appropriate access should be revoked.
For role changes, unnecessary access should be removed and new access granted based on the new role.
This connects directly with:
- A.5.15 — Access Control.
- A.5.16 — Identity Management.
- A.5.18 — Access Rights.
Step 5 — Recover Organizational Assets
Assets may include:
- Laptop.
- Mobile phone.
- Security token.
- Access card.
- USB/storage device.
- Hardware security key.
- Documents.
- Company equipment.
The organization should record the return where appropriate.
Step 6 — Handle Authentication Information
Depending on the systems involved, the organization may need to:
- Disable user accounts.
- Revoke sessions.
- Revoke tokens.
- Remove API keys.
- Rotate shared credentials where necessary.
- Transfer ownership of accounts/resources.
- Remove SSH keys.
- Remove certificates where applicable.
Particular care is required for privileged users.
Step 7 — Transfer Business Responsibilities
Before departure, appropriate responsibilities may need to be transferred.
Examples:
- Cloud administration.
- Customer accounts.
- Security monitoring.
- Production systems.
- Project ownership.
- Supplier relationships.
- Documentation.
- Incident-management responsibilities.
This helps prevent the organization from becoming dependent on one individual.
Step 8 — Communicate Continuing Responsibilities
Where applicable, departing personnel should be reminded of obligations such as:
- Confidentiality.
- Non-disclosure.
- Protection of intellectual property.
- Return of organizational information.
- Deletion of organizational information.
- Continuing contractual obligations.
This communication should be consistent with the person’s applicable agreements and legal requirements.
Step 9 — Complete Offboarding Evidence
Maintain evidence showing that required actions were completed.
For example:
| Offboarding Activity | Status |
|---|---|
| HR termination processed | Complete |
| Manager notified | Complete |
| SSO disabled | Complete |
| Email disabled | Complete |
| Cloud access removed | Complete |
| Git access removed | Complete |
| VPN access removed | Complete |
| Physical access revoked | Complete |
| Laptop returned | Complete |
| Security token returned | Complete |
| Confidentiality obligations communicated | Complete |
| Business ownership transferred | Complete |
Startup Example
Consider a 35-person SaaS startup.
A senior developer resigns.
The developer has access to:
- GitHub.
- AWS.
- Production database.
- Monitoring.
- CI/CD.
- Slack.
- Customer support platform.
The startup’s offboarding process is triggered by HR.
Flow
HR records termination
↓
Manager confirms effective date/time
↓
IT/Security prepares access-removal checklist
↓
User accounts disabled
↓
AWS/GitHub/CI/CD access revoked
↓
Production privileges removed
↓
Sessions/tokens reviewed and revoked
↓
Laptop and security keys returned
↓
Project ownership transferred
↓
Continuing confidentiality obligations communicated
↓
Offboarding evidence completed
This creates a controlled termination process.
Example: Role Change
An employee moves from:
System Administrator → Project Manager
The employee previously had:
- AWS administrator access.
- Production database access.
- Security monitoring access.
- Server management access.
After the role change:
HR/Manager
↓
Role change recorded
↓
Access review
↓
Administrator privileges removed
↓
Project-management access granted
↓
Security training requirements reviewed
↓
Access records updated
This is important because a role change can create excessive access even though the person has not left the organization.
Startup-Focused Quick Summary
A startup can implement A.6.5 with a simple Joiner-Mover-Leaver (JML) process.
Joiner
New employee
→ Security responsibilities
→ Training
→ Appropriate access
Mover
Role changes
→ Review access
→ Remove unnecessary permissions
→ Add new permissions
→ Update responsibilities
Leaver
Employee leaves
→ Disable access
→ Revoke privileges
→ Recover assets
→ Transfer responsibilities
→ Communicate continuing obligations
Simple principle
Every employee change should trigger a security review—not just a termination.
Joiner-Mover-Leaver Security Model
| Event | Security Action |
|---|---|
| Joiner | Establish identity and appropriate access |
| Role Change | Review and modify access |
| Promotion | Review additional privileges |
| Department Transfer | Remove old access and grant new access |
| Privileged Role Change | Review privileged access |
| Contractor End | Revoke contractor access |
| Termination | Disable access and recover assets |
| Retirement of Account | Revoke credentials/tokens where applicable |
Example Termination Checklist
A practical startup checklist may include:
HR
- Termination/contract end confirmed.
- Effective date/time recorded.
- Manager notified.
- Relevant continuing obligations reviewed.
IT/Security
- SSO disabled.
- Email disabled.
- VPN disabled.
- Cloud access removed.
- Git repository access removed.
- Production access removed.
- SaaS applications reviewed.
- Security tools access removed.
- Sessions/tokens revoked where appropriate.
- SSH/API keys handled.
- Privileged access removed.
Assets
- Laptop returned.
- Mobile device returned.
- Security token returned.
- Access card returned.
- Storage devices returned.
Business
- Project ownership transferred.
- Customer responsibilities transferred.
- Supplier responsibilities transferred.
- Documentation transferred.
Finalization
- Continuing obligations communicated.
- Offboarding evidence completed.
- Manager/HR confirmation received.
Example Role Change Checklist
When an employee changes roles:
- Old role identified.
- New role identified.
- Existing access reviewed.
- Unnecessary access removed.
- New access requirements approved.
- Privileged access reviewed.
- Group memberships updated.
- Application access updated.
- Physical access updated where applicable.
- Security responsibilities updated.
- Required training identified.
- New access approved.
- Evidence retained.
Audit Evidence for A.6.5
An auditor may request:
Policies and Procedures
- Joiner-Mover-Leaver Procedure.
- Employee Offboarding Procedure.
- Access Revocation Procedure.
- Role Change Procedure.
- Asset Return Procedure.
- Termination Security Checklist.
Employment Documentation
- Employment agreements.
- Confidentiality agreements.
- NDA records.
- Employee handbook.
- Contractor agreements.
Access Evidence
- Account disablement records.
- Access revocation records.
- Group membership changes.
- Privileged access removal.
- Application access logs.
- SSO records.
Asset Evidence
- Asset return checklist.
- Laptop return records.
- Security token return.
- Access card return.
Role Change Evidence
- Role-change approvals.
- Access reviews.
- Updated permissions.
- New access approvals.
Continuing Responsibilities
- Exit acknowledgement.
- Confidentiality reminders.
- NDA records.
- Return/deletion confirmations where applicable.
Audit Checklist for A.6.5
Before an ISO 27001 audit, ask:
- Is there a documented employee offboarding process?
- Does it cover contractors where applicable?
- Does the process cover role changes?
- Are responsibilities clearly assigned?
- Are termination dates communicated to IT/security?
- Is access disabled promptly according to organizational requirements?
- Are privileged accounts addressed?
- Are cloud and SaaS accounts included?
- Are API keys, tokens and SSH keys addressed where relevant?
- Are company assets returned?
- Are business responsibilities transferred?
- Are continuing confidentiality obligations communicated?
- Are role changes followed by access reviews?
- Are unnecessary permissions removed?
- Are offboarding records maintained?
- Can the organization demonstrate evidence of completed offboarding?
Common Mistakes in Implementing A.6.5
1. Treating A.6.5 as only an HR process
HR may process the employee’s departure, but security must also address:
- Accounts.
- Access.
- Credentials.
- Assets.
- Data.
- Privileges.
2. Forgetting SaaS applications
Startups may have dozens of cloud applications:
- Google Workspace/Microsoft 365.
- GitHub.
- AWS/Azure/GCP.
- Slack.
- Jira.
- CRM.
- HR platforms.
- Customer support systems.
Offboarding should consider the actual technology environment.
3. Removing email but forgetting cloud access
Disabling email does not necessarily revoke access to:
- AWS.
- GitHub.
- Databases.
- VPN.
- SaaS applications.
4. Ignoring role changes
An employee can remain inside the company while retaining excessive access from their previous role.
5. No ownership transfer
If only one person knows how to manage an important system, their departure can create operational and security risk.
6. Shared accounts
Shared administrative accounts make it difficult to determine whether a departing employee still has access.
Where possible, use individual accounts and appropriate access controls.
7. No evidence
The company says:
“We always remove access when someone leaves.”
But there is no checklist, ticket or system evidence.
8. Forgetting contractors
Contractors, consultants and temporary workers may have significant access.
Their engagement end should trigger appropriate access review.
9. Treating all departures identically
A privileged administrator may require a different level of coordination from an employee with no access to sensitive systems.
The process should be risk-based.
Practical Startup Implementation Model
A simple model is:
Trigger
Employee leaves or changes role.
↓
Identify
Identify systems, assets and responsibilities affected.
↓
Review
Review current access and privileges.
↓
Revoke / Modify
Remove or modify access.
↓
Recover
Recover organizational assets and information where applicable.
↓
Transfer
Transfer business and technical responsibilities.
↓
Communicate
Communicate continuing security obligations.
↓
Verify
Confirm that required actions are complete.
↓
Record
Maintain evidence.
Simple formula
Trigger → Identify → Review → Revoke/Modify → Recover → Transfer → Communicate → Verify → Record
Policy vs. Process vs. Evidence
| Category | Example |
|---|---|
| Policy | Human Resources Security Policy |
| Policy | Access Control Policy |
| Process | Joiner-Mover-Leaver Procedure |
| Process | Employee Offboarding Procedure |
| Process | Role Change Procedure |
| Process | Access Revocation Procedure |
| Process | Asset Return Procedure |
| Evidence | Offboarding Checklist |
| Evidence | Termination Ticket |
| Evidence | Account Disablement Record |
| Evidence | Access Revocation Report |
| Evidence | Asset Return Record |
| Evidence | Role Change Access Review |
| Evidence | Privileged Access Removal |
| Evidence | Exit Acknowledgement |
Simple rule
HR identifies the employment change.
Security and IT manage the security impact.
Managers confirm business responsibilities.
Evidence proves the required actions were completed.
Relationship with Other ISO 27001 Controls
A.6.5 connects strongly with:
| Control | Relationship |
|---|---|
| A.6.1 | Screening before employment |
| A.6.2 | Security responsibilities during employment |
| A.6.3 | Security awareness and training |
| A.6.4 | Disciplinary process |
| A.6.5 | Responsibilities after termination/change |
| A.6.6 | Confidentiality/NDA |
| A.6.8 | Security event reporting |
| A.5.15 | Access control |
| A.5.16 | Identity management |
| A.5.17 | Authentication information |
| A.5.18 | Access rights |
| A.5.28 | Collection of evidence |
| A.5.32 | Intellectual property rights |
| A.5.34 | Privacy and PII |
A.6.2 vs. A.6.5
These controls cover different points in the employment lifecycle.
A.6.2
During employment relationship
What security responsibilities does the employee have?
A.6.5
When employment or role changes
What responsibilities continue, what access must change, and what security actions must occur?
Example
A.6.2
Employee agrees to protect company information.
↓
A.6.3
Employee receives security training.
↓
A.6.5
Employee leaves.
↓
Access is revoked + assets returned + continuing confidentiality obligations communicated.
A.6.5 and Access Control
A.6.5 and A.5.18 work particularly closely.
A.6.5
Identifies the employment or role change.
A.5.18
Ensures access rights are appropriately reviewed, modified or revoked.
For example:
Employee changes from Developer → Sales
↓
A.6.5 triggers role-change process.
↓
A.5.18 reviews access rights.
↓
Developer privileges removed.
↓
Sales permissions granted.
This creates a controlled identity lifecycle.
Useful Documents for A.6.5
Organizations may create:
- [Insert Draft Document Link] — Employee Offboarding Policy
- [Insert Draft Document Link] — Joiner-Mover-Leaver Procedure
- [Insert Draft Document Link] — Employee Termination Security Checklist
- [Insert Draft Document Link] — Employee Role Change Checklist
- [Insert Draft Document Link] — Access Revocation Checklist
- [Insert Draft Document Link] — Asset Return Checklist
- [Insert Draft Document Link] — Privileged User Offboarding Checklist
- [Insert Draft Document Link] — Contractor Offboarding Procedure
- [Insert Draft Document Link] — Exit Security Acknowledgement
- [Insert Draft Document Link] — Access Revocation Evidence Register
- [Insert Draft Document Link] — Personnel Security Audit Checklist
Questions an Auditor May Ask
Termination
“What happens when an employee leaves?”
“Who informs IT and information security?”
“How quickly are accounts disabled?”
Access
“How do you make sure former employees cannot access company systems?”
“How do you handle privileged users?”
“How do you handle cloud and SaaS applications?”
Role Changes
“What happens when someone changes departments?”
“How do you remove access from the old role?”
Assets
“How do you ensure company laptops and security devices are returned?”
Continuing Obligations
“What security responsibilities continue after termination?”
“How are those responsibilities communicated?”
Evidence
“Show me the offboarding record for a recently departed employee.”
“Can you demonstrate that their access was removed?”
Startup-Focused Final Takeaway
ISO 27001 Annex A 6.5 is about ensuring that employment changes do not create security gaps.
For a startup, the most practical approach is to build a simple Joiner-Mover-Leaver security process.
When someone joins
Establish responsibilities → Train → Grant appropriate access
When someone moves
Review access → Remove old privileges → Grant new access
When someone leaves
Disable access → Revoke privileges → Recover assets → Transfer responsibilities → Communicate continuing obligations
The key questions for A.6.5 are:
“What happens to a person’s access when they leave or change roles?”
“How do we ensure unnecessary access is removed?”
“Which information security responsibilities continue after termination?”
“Can we demonstrate that our offboarding and role-change process actually happened?”
A strong implementation does not depend on someone remembering to remove access manually.
It creates a repeatable process:
HR/Manager Trigger → Security Review → Access Change → Asset Recovery → Responsibility Transfer → Verification → Evidence
That is what turns employee termination and role changes from an informal HR activity into a controlled information security process.