Most organizations start their IAM strategy with the tool
Not long ago, someone on LinkedIn asked what the cool support ticket software is. He went straight to the tool, before saying how his team handles a problem, who decides what gets fixed first, or what the business needs from support. I see the same reflex in identity and access management strategy, where it’s the most expensive mistake I run into.
In identity, the question often sounds like, “Which platform should we buy?” People ask it before they’ve decided who approves access, what a new hire gets on day one, or how fast a terminated employee loses everything. Those are business decisions. A tool can’t make those calls for you. Until somebody does, it just runs on whatever defaults came with the software.
The tool is the last thing I pick, because it can only carry out decisions people have already made and written down. Pick the platform first, and you’ll configure it around questions nobody answered.
Six questions tell you whether it’s a policy or a process
Most people can’t tell a policy from a process, and I don’t blame them.
Policies and processes usually get written in the same document, by the same person, in the same meeting. The fastest way I know to pull them apart is to ask six questions: why, who, what, how, when, and where. I use them in every IAM strategy I build, because each answer tells me which layer owns it.
Each question belongs to one layer.
- Why is the purpose, the outcome the organization wants. It sits above the policy and starts it.
- Who covers the people who own the decision, approve it, and do the work.
- What is the policy. It states what must be true.
- How and when are the process. They set the steps and the deadline.
- Where is the system. It’s where the process runs and where the record lives.
Take terminated employees as an example. The why is keeping the organization’s systems and work safe when someone leaves on bad terms. The what is that a terminated employee loses access at the time of termination. The how and when are the steps that remove each account and the deadline for each one. The where includes entitlements, the directory, and every application that keeps its own accounts. The who is the person with authority to sign the policy and the process owner who runs the removal.
Here are two versions of a termination policy.
- A terminated employee loses access at the time of termination.
- The help desk disables the directory account, then emails each application owner.
The first states what must be true and leaves the steps to the process. The second is a process step written as a policy. It never says when access must be removed, so the process has to invent a deadline, and a system built on that process automates the invented answer. It also ties the help desk’s routine to whoever approved the policy, so every change to those steps has to go back up for approval.
Follow the termination policy. It says access ends at the time of termination, so the process must meet that deadline, which means work starts the moment the termination is recorded, not when someone gets around to it. The process then needs systems that can do the job, so every application that keeps its own accounts has to let that account be removed at that moment.
Policy, process, and system are links in a chain, and they have to align in that order. The organization’s desired outcome rests at the end of that chain. If the process can’t meet the policy’s deadline, or a system can’t do what the process needs, the outcome fails no matter how well the other links hold. Fix the link that broke. Sometimes that really is the policy, such as a deadline nobody can meet, but then its approver changes it because the purpose calls for it, never to suit a tool.
An IAM strategy starts with the outcome the organization wants
Every IT decision I make starts with one question: what outcome does the organization want? That’s the why. Until someone answers it, there’s nothing to write a policy about and nothing for a system to do.
At the college, the outcome was accountability. Every other problem on the list traced back to not knowing who did what, so identity had to come first.
IT is people, so the next question is who. IT runs the controls, but IT can’t own a business decision. Whether a contractor keeps access after a project ends, or how fast a departing employee loses it, is a call for someone with authority over the business, and that’s who owns the result.
That’s why the plan went to the CFO and the CEO for approval instead of staying inside IT. The outcome belonged to the people who ran the school.
Write the decision down so politics can’t undo it
Decisions fail on politics before they fail on technology. An executive who wasn’t in the room, or who didn’t like the answer, can reopen any decision whose purpose nobody wrote down. If all you have is everyone’s memory of the meeting, the loudest person in the next meeting wins.
A decision someone remembers from a meeting isn’t a policy. Neither is a rule the help desk follows because it always has, or an executive’s email. If it isn’t written and approved, it isn’t policy. Approved means signed by someone whose authority covers everyone the policy binds, and until that happens, the answer is still up for grabs.
A policy that binds the whole company needs an approver whose authority covers the whole company, such as the board of directors or the CEO. A policy for one division or one department can be approved by that division’s or department’s management, and where those lines sit depends on the organization. The more people a policy binds, the higher it has to go for approval. That’s why a department head can’t approve a company-wide policy, and IT can’t approve one that binds the business.
When the help desk changes how it removes accounts, the process owner approves the new steps. That person is accountable for getting the work done the way the policy requires. The policy approver doesn’t have to sign off again because the policy only states what must be true.
Writing it down changes the argument. When the purpose, the policy, and the owner’s name are on paper, the question stops being who has more pull and becomes what has changed since we decided. If nothing has changed, the decision stands. If something has, the owner reopens it on purpose, and everyone can see why.
A policy covers one issue and states the decisions on it
Open a real policy, and you’ll find a document about one issue, such as acceptable use or ending a terminated employee’s access. It explains why the policy exists, who it applies to, what management decided, who is responsible for what, and what happens when someone doesn’t comply. It also names who approved it and when it gets reviewed. NIST describes most of these parts in chapter 5 of An Introduction to Information Security. The decisions are written as requirements, with must or shall, in words the people bound by the policy can understand without asking IT.
At the college, the first policies came straight out of the interviews, and each covered one issue. The privileged access policy removed administrator rights from employees who didn’t need them, which was most of them. The acceptable use policy set the rules for school resources, with provisions for what each department needed to do its work. The termination policy separated a user from an active account at the time of termination.
Each of those answers what must be true. None of them says which screen to open or which command to run. Keep the steps out, and the policy survives every change to the tools underneath it. In an identity and access management strategy, these policies are what every later decision about roles, access reviews, and platforms gets measured against.
Every policy needs a decision record:
- the purpose
- the reasoning
- the options you turned down
- the owner’s name
The policy is what people follow, and the record is what stops the next reorganization from undoing it.
A process turns the policy into work with an owner and a deadline
When I arrived, the college had no ticket system. Nobody could track a problem from the first report to the fix, and nobody could prove that a terminated employee’s account had been closed. I put one in as part of the change, because the termination policy meant nothing if we couldn’t show the work got done.
The termination process needed five parts.
- An owner is accountable for getting the work done.
- The termination itself is the trigger, so the work starts without anyone having to remember it.
- The steps remove every account and entitlement the person holds.
- The deadline is the moment of termination.
- A record shows what was removed, when, and by whom.
The deadline came from what the school had already been through. Terminated users who left angry had sabotaged systems or walked off with the school’s work product. Leaving an account open until the end of the week gave the next one the same chance.
The record is the part people skip. With the ticket system in place, a termination could be tracked like any other request, from the moment it came in to the moment the last account closed. That record is what lets you prove the process works instead of hoping it does.
A system runs whatever process you give it
A system is where the process runs and where the record lives. It automates whatever process you give it, flaws included, which is why it comes last.
Here’s what I inherited at the college. The network ran on consumer-grade Linksys devices. There was no Active Directory and no site-to-site connection between the five campuses. Staff ran school business over Facebook Messenger on personal accounts, so school documents left with whoever held the account, terminated users included.
None of that started as a technology problem. Nobody had decided where school records should live or who should hold them, so people used whatever they had. Better equipment alone wouldn’t have fixed it. Once the policy and the process were settled, I knew what the systems had to do.
In an IAM strategy, that’s what a pre-purchase review is for. The policy and the process become a requirements list, and every candidate system gets measured against it. Not every system can run every policy or process. A platform that only syncs accounts overnight can’t meet the termination requirement, no matter how it’s configured.
When nothing on the market fits, work back up the chain in order. Change the process first: a manual step for the applications a system can’t reach still meets the policy if it has an owner, the same deadline, and a record. If that isn’t enough, close the gap with configuration, a custom connector, or a small build, and count that cost before you sign. If nothing can meet the requirement, take it to the policy’s approver, who either accepts the risk in writing as an exception or changes the requirement because the purpose allows it.
Never buy the closest product and let its defaults rewrite the policy. The problem doesn’t go away. It shows up at audit.
Where I start when someone asks me for an IAM strategy
When someone asks me for an identity and access management strategy, I don’t start with a vendor list. I start with the same order I used at the college.
- Confirm the outcome. What does the organization want, and why? At the college, it was accountability: knowing who did what.
- Find the owner. Who has authority over everyone the decision affects? At the college, that was the CFO and the CEO.
- Get the policy written. One policy per issue, written so the people it binds can understand it, and approved at the level that matches its scope.
- Define the process. Name the process owner, the steps, the deadline, and the evidence that proves the work happened.
- Choose or configure the system. By now you know what it has to do, where the record lives, and who runs it.
If you’re about to buy an identity platform, stop at step one this week. Write down the outcome you want and the name of the person who owns it. If you can’t fill in both, you’re not ready to talk to vendors.
