ISO 27001 Control 6.5: Responsibilities After Termination or Change of Employment

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

In short: ISO 27001 control 6.5, responsibilities after termination or change of employment, requires security duties that continue after someone leaves or changes role to be defined and enforced. In practice that means a leavers and movers checklist that removes access on the day, recovers equipment and data, and covers shared and service accounts the person knew.

When someone leaves, most organisations disable their account. That part usually happens. What happens to everything else is far less certain.

I have repeatedly seen people leave and take their company laptop with them as part of a severance deal, with the business perfectly happy about it. I have found, over and over, people who have left but still know the passwords to generic admin accounts that can be reached from the internet. And I once worked with an organisation whose systems were joined together with hard-coded generic passwords that nobody understood, so when a key member of staff left, they still, in theory, had administrative access to everything.

Control 6.5 is about the responsibilities that continue after someone leaves or changes role, and making sure they are defined, communicated and enforced. This page covers that, and the practical steps that go with it. There is a free leavers and movers checklist further down.

What control 6.5 actually asks for

The control requires information security responsibilities and duties that remain valid after termination or change of employment to be defined, enforced and communicated to the relevant people. In practice:

• Define what continues. Confidentiality above all, plus any duties about intellectual property, client information and returning information.
• Communicate it. Remind the person at the point they leave, not just in the contract they signed years ago.
• Enforce it. Make it real: recover equipment and information, and remove the ability to keep accessing it.
• Cover movers as well as leavers. A change of role ends some responsibilities and access, and starts others.
• Cover contractors and suppliers. When an engagement ends, the same applies.

In the 2013 edition this was control A.7.3.1. It sits alongside several other controls that do the practical work at the point of leaving.

The laptop that went home

Letting a departing employee keep their laptop is common, especially as part of a settlement, and often a kind gesture. The problem is what is on it. Cached email, synced files, saved passwords, browser sessions still signed in to company systems, and sometimes a VPN client that still connects.

If a device is going with the person, wipe it first and then hand it over. A full reset, not a deleted folder. Remove it from your device management and from any conditional access trust before it leaves. Otherwise you are potentially leaving a doorway into your data and services open, held by someone who no longer works for you and whose relationship with you may not be entirely happy.

Generic accounts and the passwords people take with them

This is the most dangerous gap, and it is very, very common. Disabling someone’s named account does nothing about the shared accounts they used: the generic “admin” login on the firewall, the shared account for the domain registrar, the social media logins, the cloud console root account, the Wi-Fi password. If those can be reached from the internet, the person who left can still reach them.

I was once brought in to an organisation after a key member of staff had left. Their services were connected in a complicated web, with generic passwords hard-coded into the connections between systems. None of it was documented, and nobody remaining understood how it fitted together. My job was to document the systems and help them understand how it all worked. Along the way I found multiple access accounts whose passwords had never been changed. The person who had left could, in theory, have logged in to administer almost everything. It was a really dangerous position to be in, and nobody had realised.

What prevents this:

• Keep a register of shared and generic accounts, with who knows each password. The leavers checklist then tells you exactly which to change.
• Change every shared credential the person knew, on the day they leave.
• Reduce shared accounts. Named accounts with appropriate rights are easier to remove. Use a password manager with shared vaults where sharing is unavoidable, so access can be revoked.
• Find hard-coded credentials. Service accounts and keys embedded in systems should be documented, owned and rotated, under control 5.17.
• Restrict admin interfaces. Admin consoles should not be reachable from the whole internet with a password alone.

If your systems only make sense to the person who built them, that is also a documented procedures problem, and it is better fixed before they hand in their notice.

What continues after they go

The responsibilities side of this control is easier. Most employment contracts already include confidentiality that survives the end of employment, as covered in control 6.2 and control 6.6. The gap is that nobody reminds the person.

At the exit, give them a short written note, or cover it in the exit conversation and record that you did: what they must keep confidential, that they must not keep or use company or client information, and that they must return everything. It takes five minutes, it removes any doubt, and if something does go wrong later it is evidence that they knew.

Movers: the forgotten half

People who change roles keep their old access far more often than leavers do, because nobody triggers a review. Over a few years, someone who has moved from operations to finance to IT can end up with access to all three. When someone moves, review their access against the new role, remove what they no longer need, and consider whether the new role needs higher screening under control 6.1.

What auditors will look for

Leavers are where I find the most live access that should not exist, so I sample recent ones.

1. The leavers process. Is there a checklist, and does it cover continuing duties as well as access and equipment?
2. A recent leaver, traced. When did they leave, when was their account disabled, what happened to their device, and were they reminded of their continuing obligations?
3. Shared accounts. Which shared or generic accounts did they know about, and were those passwords changed?
4. A mover. Pick someone who changed role. Was their access reviewed?
5. Contractors. When an engagement ended, what was done?

Common issues

• Laptops kept by leavers without being wiped.
• Shared and generic admin passwords never changed when someone leaves.
• Hard-coded credentials nobody knows about, in systems nobody understands.
• Movers keeping access from every previous role.
• No reminder of continuing confidentiality at exit.
• Contractor access left active after the engagement ends.

The self-check

Think of the last person who left, and the systems they could reach.

• Which shared or generic accounts did your last leaver know the password to, and have they all been changed?
• Are any of those accounts reachable from the internet?
• What happened to the last laptop a leaver was allowed to keep?
• Does anyone in your business know credentials that are hard-coded into your systems?
• When someone last changed roles, was their old access removed?

The first is the one to sit with. If you cannot answer it, nor can anyone else.

The leaver who still had a way in

In a business of ten people, removing a leaver’s access is easy, because one person usually manages everything. Above about 100 staff it becomes much harder, because ownership of systems is spread out. I have seen IT remove the accounts it manages after a notification from HR, while access to cloud platforms and project management tools run by other teams stayed live.

The most serious case I have seen involved a small UK technology company. A developer left on bad terms. He had set up an account for a colleague, who had never changed the default password, and after leaving he used it to get back in and posted the access details on public forums. Attacks began almost immediately. Good out-of-hours alerting and good logs limited the damage, and I tell that part of the story under control 8.15. The root cause, though, was a leaver process that covered the leaver’s own accounts but not the ones he knew the passwords to.

In the small technology businesses I mostly audit now, I rarely find a named leaver whose own account is still live: there is too little staff turnover for it to build up, and one person usually manages everything. In larger organisations of 200 or more, like the ones I worked in earlier in my career, it is a constant problem, and regular access reviews become a necessary routine. The more complex the organisation, its systems and its people, the more likely it is. In businesses of every size, though, the real problem is the same one: generic and shared accounts whose credentials are not changed when someone who knew them leaves.

How control 6.5 links to other clauses and controls

• Control 5.11, Return of assets. Recovering devices and information.
• Control 5.17, Authentication information. Changing shared and hard-coded credentials.
• Control 5.18, Access rights. Removing access for leavers and reviewing it for movers.
• Control 6.2, Terms and conditions of employment. Where continuing duties are first set out.
• Control 6.6, Confidentiality or non-disclosure agreements. The agreement whose terms continue.
• Control 5.37, Documented operating procedures. So knowledge does not leave with the person.

Frequently asked questions

Sources and further reading

Official legislation, standards and guidance referred to on this page.

• Password administration for system owners. NCSC guidance on managing and changing credentials.
• ISO/IEC 27002:2022. The implementation guidance that accompanies the controls.
• Device security guidance. NCSC guidance on managing and resetting devices.
• Employment information. ICO guidance on handling former workers’ personal data.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call