A few weeks ago I looked at a login log. It belongs to one of our portal agents, built for a logistics customer. Every ten minutes it logs into a customer portal. It pulls the current status. Then it logs out again. Over 6,500 runs since late July. Almost all successful. Every run with a timestamp. The log was not built for ISO 27001. It is a byproduct. Of the automation itself. But it is exactly what an auditor wants to see. During an access review. And exactly what most forwarders do not have.
My position: the ISO 27001 access record does not fail because of the standard. It fails because of where the access lives. The sensitive accounts sit outside the system IT controls.
ISO/IEC 27001:2022 sets this out in Annex A.5.18. Access rights get granted. They get changed. They get removed. Under a fixed rule. They get reviewed on a schedule. Does the access still fit the role? On exit, access must go right away. On a role change too. Every change needs a trail. Who requested it? Who approved it? What changed? The control folds three older rules into one. From the 2013 version. And makes them stricter.
Annex A.8.2 goes further. For privileged access. It asks for a formal process. For granting and revoking it. Nobody should hold more rights than the role needs. Privileged access belongs on individual accounts. Not on shared credentials. A login used by several people is itself a finding.
This is not a niche standard. The ISO Survey 2024 counts 96,709 valid ISO 27001 certificates worldwide. In logistics, more large shippers demand the certificate every year. As a condition for the contract. Not as a nice-to-have.
Most certified forwarders have their own Active Directory under control. An employee joins. They get an account. They leave. The account gets disabled. There is a process for that. Often even a ticket.
Everything else runs around it. A mid-size forwarder typically runs ten to thirty customer portals. Transporeon tenants. Web portals from individual key accounts. The customs portal. The toll portal. One or two telematics systems. Each with its own login. Outside the AD. Mostly outside any central directory. Dispatch keeps the credentials in a spreadsheet. Sometimes in a shared notebook at the desk. When a customer portal changes, whoever has a minute logs in. With whichever login still works. That is exactly what A.8.2 does not want.
For the quality manager or the information security officer, that means a lot of work. The audit record does not come from a system. It comes from asking around. Does the colleague who left three months ago still have portal access? Nobody quite knows. The honest answer is usually: we are not sure.
The security officer is formally responsible for the review. He sees the AD. He sees the mail system. He does not see the twenty customer portals. They run in dispatch's browser tabs. With no central log. With no signal reaching him.
We build the portal automation anyway. Customer portals without an API need manual work otherwise. The access inventory for ISO 27001 falls out almost for free. If four things run cleanly.
First, every portal agent writes a login log. Timestamp, portal, account, result. The exact line from the example above. It answers the auditor's question directly. Who accessed what, and when?
Second, credentials sit in a secret vault. Not in a spreadsheet anymore. The agent reads them on login. A human rarely sees them on screen. That also ends the habit of passing logins around by word of mouth.
Third, a weekly match. HR's staff list against active accounts. An account with no matching person lands on a list. A person with no contract, but an active account, too. One line per case, nothing more.
Fourth, an alert on any login after an exit date. This is the hardest case for A.5.18. And the only one where automation actually prevents something. Not just documents it.
The side effect is the interesting part. Once every login carries a timestamp and an account, shared logins become visible. An account logs in from one place in the morning. From another at noon. Both supposedly the same person. That is a candidate for the review list. Nobody saw this before. Now the log does.
A ready-made privileged access management product often costs more than it is worth for ten to thirty external accounts. Vendors build for hundreds of accounts. For a data center. A forwarder with twenty customer portals does not need a data center tool. It needs a log. And an alert. Both fall out of the automation that gets built anyway.
On the day a portal changes, little changes. The new credential goes into the vault. The agent uses it. Done.
On the day someone leaves, more changes. Disabling the AD account is no longer the only step. The match shows which external accounts are still affected. It flags them for a check.
On audit day, the most changes, but earlier. The compliance lead exports a table. Instead of asking colleagues for a week. The ISO 27001 record becomes an export. Not a search.
Three honest limits.
Not every portal logs cleanly. Some vendors require a two-factor confirmation on a phone. Then the login stays manual. The log still works. The person confirms with a tap. The timestamp still lands in the line.
Not every account maps to one person. Some portals only know one company login. No account per employee. Then only one question remains. Who knew the password? When was it last changed? That is still a finding. Just a weaker one.
An access inventory is not an identity management system. It does not replace a tool for privileged access. It only answers: who had access, and when? Not: who is allowed to do what? For ISO 27001, that is enough for the review. For ten to thirty portals. The policy itself, who should have access to what, no agent can set that. That decision sits with management or the security officer. Automation supplies the basis. Not the decision.
A secret vault for credentials. A login log per portal agent, with timestamp and account. A weekly match against the staff list. A rule that flags a login after an exit date. An export as evidence for Annex A.5.18 and A.8.2. None of this is exotic. What is new is that it exists at all for the portals outside the AD.
How many customer portals does your dispatch team carry in their heads, not in a system? Send me the number. If it surprises you, I will show you the access inventory for exactly those portals in a process check.
