Identity and Access Management Implementation: How to Set It Up

Identity and access management implementation means getting everyone’s accounts under one set of rules and one sign-in, in an order the firm can follow. This guide is for an IT manager or owner at a firm in India or the GCC with logins spread across applications. It covers employees and others who work for the firm, but it names no tool. The guide has nine steps, each with a decision and a yes/no check, and the order and the checks are Signisys’ own working method. NCSC’s 10 Steps identity page, UK guidance for cyber security professionals published on 11 May 2021, says what the policy and controls should cover but gives no numbered build order; the order here is ours. If you need a plain definition of the term, see the glossary’s plain definition.

Identity and Access Management Implementation in Short: Nine Steps in Order

The nine steps run in a set order, but the first three need only lists a firm already holds. If a step has no recorded “yes”, it counts as not done. This build is easier to follow when each step ends in a check with only two answers.

Identity and Access Management Implementation: What NCSC and NIST Say, and What Is Ours

NCSC’s identity page lists what the policy and controls should cover and gives no numbered build order. The NIST CSF 2.0 (CSWP 29), dated 26 February 2024, lists outcomes but does not prescribe how to reach them. Although both sources cover the subject, neither sets out numbered steps for building it. The nine steps and their order are Signisys’ own, and the table shows which outcome each step serves.

NIST’s category PR.AA reads: “Access to physical and logical assets is limited to authorized users, services, and hardware and managed commensurate with the assessed risk of unauthorized access”. It also covers services, hardware and physical access, which this guide leaves out. The mapping below is ours alone, and the framework does not state it.

This guide does not map PR.AA-02 (identity proofing) or PR.AA-04 (identity assertions), which sit outside its scope.

Identity and Access Management Implementation, Steps 1 to 3: Know Who and What Exists

These three steps need lists and a decision; no purchase is involved. The order is Signisys’ own. Identity and access management implementation starts here, with knowing who and what exists.

Step 1: List Every Person Who Should Have Access

Start from the HR record, and add anyone who works for the firm but is not on payroll. NCSC’s page says: “Make sure you consider all potential types of user including full and part-time staff, contractors, volunteers, students and visitors.” NCSC’s list is wider than this guide, which follows it only for people who work for the firm.

Keep one list with one named owner and one column for status, such as working, on leave or left. Job roles can wait until Step 7.

Decision: whose list is the master for who works here, and who adds people who are not on payroll.

Leave until later: job roles.

Step 2: Match Every Account to a Person

Pull the account list from each business application, the email system and the remote-access setup, and set each against the Step 1 list, to see which accounts have no person against them. Each account ends in one of three outcomes: matched, unmatched and owned, or unmatched and unowned.

Here NCSC says: “Temporary accounts (perhaps created to test processes) should also be removed or suspended when no longer required.” Shared accounts get a named owner or a replacement (our view). Hunting for leftover access after the fact is a different job, which a companion article on the warning signs of weak employee access covers.

Decision: for each unmatched account, a person decides whether to assign an owner or switch it off. Ask the likely owner before switching off an account you can’t trace.

Leave until later: machine, service and agent accounts, which the last section links to.

Step 3: Choose One Home for Identities

Choose the one place that sign-ins draw on. In this guide, a directory means that one list of identities the firm treats as the master for sign-in, but it is not a product.

A firm that already signs people in to email may already run one; ask whether it can be the home. A tool choice may arise here, but it is a decision for a person, and a later article covers choosing.

Decision: use the directory you already run, or add one, and write the reason beside the choice.

Leave until later: connecting every application, which is Step 5.

Identity and Access Management Implementation, Steps 4 to 6: Rules, Sign-In and a Second Check

These three steps set who may reach what, and how people prove who they are. In our order, rules come before sign-in, as a connected application with no written rule has nothing to measure it against. This part of identity and access management implementation ends with administrators on separate accounts, as well as a second check.

Step 4: Write the Access Rules

Write one page that says who may reach which system, and why. NCSC says the policy should cover “who should have access to which systems, data or functionality, why, and under what circumstances”, with the words who, why and what in italics on its page. The one-page format is ours, although NCSC calls the document a policy.

Use one row per key system, and also name the approver. Add a condition, such as access only from a managed laptop, if the firm can enforce it. NCSC adds that policies reach beyond systems you run, to online services where staff can sign up with a work email address; add a line for those. NCSC’s page starts with the policy, but here the lists in Steps 1 to 3 come first, as the policy names real people and systems; that placement is our choice.

Decision: who approves access to each key system, and who approves when the approver is away.

Leave until later: detailed rule engines. Plain sentences are enough when you start.

Step 5: Put Key Applications Behind One Sign-In

Choose first the applications where an unauthorised sign-in would do serious harm, plus the ones every employee opens, and connect them to the directory from Step 3. Single sign-on means one login that opens several applications.

NCSC notes that single sign-on may be available for some online services, which helps control access and lets access be revoked along with a work account when someone leaves; in its advice on passwords it also suggests single sign-on as one way to cut the number of passwords people must remember.

Start with a small group, such as the IT team, to limit the number of people a fault touches. That is Signisys’ view. Also write awkward older applications on a list with an owner, and connect them in a later pass.

Decision: which applications go first, and the fallback if one can’t connect yet.

Leave until later: every remaining application.

Step 6: Add a Second Check and Separate Admin Accounts

In identity and access management implementation, turn on a second sign-in check, multi-factor authentication (MFA): a password plus a second proof, such as a code. For a fuller explanation of the term, see multi-factor sign-in.

NCSC’s page says to implement MFA “on any accounts for online services” and, for administrative accounts, “Ensure multi-factor authentication is enabled for administrative accounts”. For all user accounts, NCSC’s heading is softer: “Consider multi-factor authentication for all user accounts”. It also says: “Where appropriate, offer people a choice of factors to self authenticate, as no single method will suit everyone (or all environments or devices).”

Administrators first, then remote access, then everyone else is our order, not NCSC’s. NCSC also says: “Ensure admins have separate user accounts for day-to-day business (such as email and internet browsing) and another for activities requiring their administrative privileges.” The same check on mail is in our email security steps.

Decision: which second checks to offer, and what a person does if they lose theirs.

Leave until later: passwordless sign-in and vaulting of administrator accounts; each is its own subject. For what one administrator login can reach, see why attackers go after admin accounts.

Steps 7 to 9: Roles, HR Events and Reviews

The work does not end at sign-in; people join, move and leave. The last three steps keep access correct after the first pass. In our order these steps come last: roles are worked out from the people and account lists, and a review has something to look at once access is controlled.

Identity and Access Management Implementation, Step 7: Define a Few Roles From Real Jobs

Group people by job and write each job’s access in one line. A role means a named set of access that goes with a job; for the wider idea, see role-based access.

Take the people list from Step 1, group it by job, and read what each group already has from Step 2. In the NIST framework, PR.AA-05 asks that permissions incorporate “the principles of least privilege and separation of duties”. NCSC’s page does not set out roles, but this step adds them; the addition is Signisys’ own.

Decision: which jobs get a role first, and who approves access outside a role.

Leave until later: a long role catalogue, and rules that depend on location or time of day.

Step 8: Tie Access to HR Events

Let joining, moving and leaving each trigger a change in access, with the HR record as the trigger. NCSC says account management should include a “joiners, movers and leavers” policy “so access can be revoked when no longer needed, or changed for movers”. One rule per event is enough to begin; automating it is a later article.

Start with the leaver rule: name who tells IT and where to record the change. For movers, access follows the new job’s role, and the old access goes instead of stacking up.

Decision: who tells IT, and the deadline the firm sets for removing a leaver’s access. The firm sets the time, but this guide sets none.

Leave until later: automation.

Identity and Access Management Implementation, Step 9: Start Reviews and Keep Records

Name the person who reviews who has access, and set the date for when the first review happens. In its advice on privileged accounts, NCSC says to “Review user accounts and systems for unnecessary privileges on a regular basis” and gives no interval; nor does this guide. The firm sets its own, but it should write down the reason.

Also keep a record of who signed in and who changed access. On logging, NCSC says to ensure “authentication and authorisation events are logged and monitored for suspicious behaviour”.

Decision: who reviews, what they look at first (administrator accounts are a starting point, our view), and the interval.

Leave until later: a full review method, which a later article covers.

An Identity and Access Management Implementation Example: A Small Firm, Illustrative

This example is illustrative only and not a Signisys client. It uses no numbers and no durations.

A small firm writes its access page and finds that its finance system has no named approver (the Step 4 check fails). The firm’s owner names an approver and a stand-in, runs the check again and it passes. The administrators then get separate accounts and a second check (Step 6), and that check passes only once each administrator’s day-to-day and administrative accounts are separate.

A failed check sends you back a step. Fix the step and run its check again, and if the cause lies earlier, go back one step. A pass shows only the result on the day the check ran.

What to Leave Until Later, and When to Ask for Help

This guide stops at a controlled workforce sign-in. Identity and access management implementation for other kinds of account is a separate job. For administrator and service accounts, see an eight-step order of work for administrator and service accounts. Left out on purpose are machine and agent accounts (see machine and agent accounts), vaulting administrator accounts, choosing software, customer sign-in, supplier access and any regulator’s rule. This guide states none of them.

Outside help is worth having in three cases:

• Accounts that nobody can match to a person.
• An HR record that nobody can trust as the master list.
• Administrator accounts that nobody can separate.

For the wider picture, see the use case behind this guide.

Signisys helps organisations control who can access which systems, with the exact scope agreed for each engagement. See our solution, Identity and Access Management (IAM), and our service, Cybersecurity Services.

Identity and Access Management Implementation FAQ