If some SaaS accounts sit outside SSO, then how do we find and close the gaps?

Start

Some services hold their own accounts

Disabling the directory account ends access to everything connected to single sign-on, and nothing else. A service with its own accounts keeps a leaver's access until someone removes it there, which is why every such service needs a named line on the leaver checklist. Software bought on a card or signed up to with a work email address counts.

• Then: Search spend, sign-in logs, suppliers and managers

Step

Search spend, sign-in logs, suppliers and managers

Every 3 months by the pack's default, look in four places. Card and expense spend shows software bought on a company card or claimed as an expense; single sign-on and app-consent logs show apps people signed in to or granted access with their work account; the supplier register shows portals with their own accounts; line managers, at the annual profile review, name tools no list shows.

• Then: Add each service to the system inventory, with an owner

Step

Add each service to the system inventory, with an owner

Record each service with its owner, whether it uses single sign-on, and the named administrator for its local accounts. If the service is in scope for the access review, one with no owner, or no way to extract who has access, cannot be reviewed, and that gap is itself a finding. Keep the discovery results and the outcome for each service.

• Then: Does the organisation still need the service?

Decision

Does the organisation still need the service?

Decide with the service's owner. A service that is not needed, or that duplicates an approved system, is closed. In the pack's example, one of four services found in a quarter was an online survey tool that was closed.

• No, or it duplicates an approved system: Export or delete its data, then close the accounts
• Yes: Can it connect to single sign-on?

Outcome

Export or delete its data, then close the accounts

Export the data the organisation needs, or delete it, and close the accounts. Confirm in the service itself that the accounts no longer work: a closed ticket is not confirmation. If the service holds personal or sensitive data, follow your supplier exit route.

Decision

Can it connect to single sign-on?

Connect it if the service supports single sign-on: its accounts then end when the directory account ends. Make the decision with the service's owner and keep it with the discovery results. If it cannot be connected and is needed, it stays outside with its own controls.

• Yes: Connect it, then test removal with an approved test identity
• No: Name its administrator and give it a leaver checklist line

Step

Connect it, then test removal with an approved test identity

Disable an approved test identity in the directory and check its next sign-in is refused. End its sessions and check an open session in the service ends, or ends within the session lifetime the owner accepts. Wait for the token lifetime and check any token or remembered device stops working.

• Then: Did the session and token tests pass, as well as sign-in?

Decision

Did the session and token tests pass, as well as sign-in?

A blocked new sign-in does not prove that existing sessions and tokens end. Until all three tests pass, the service is not treated as covered by the directory. If the tests could not be run, treat them as failed.

• Yes, all three: Are there local accounts from before the connection?
• No, or not tested: Name its administrator and give it a leaver checklist line

Decision

Are there local accounts from before the connection?

Accounts created before the connection can still work with their own passwords, beside single sign-on, so the pack's connection tests look for them. Compare the service's user list with the people now signing in through single sign-on.

• Yes, or not known: Remove them, or link them to single sign-on
• No: Covered by the directory: its access ends with the account

Step

Remove them, or link them to single sign-on

Each account created before the connection is removed or linked to single sign-on, so that no one can still sign in with a local password. Confirm each removal in the service's user list.

• Then: Covered by the directory: its access ends with the account

Outcome

Covered by the directory: its access ends with the account

The service's accounts now end when the directory account ends, so leavers and movers are handled by the directory steps. Keep it in the system inventory: discovery runs again every 3 months by the pack's default, and the monthly reconciliation still covers every in-scope system.

Step

Name its administrator and give it a leaver checklist line

A needed service outside single sign-on gets an owner, a named administrator and a named line on the leaver checklist. Assign that line to a person, never a shared mailbox. Where the service can expire accounts, set a contractor's account to expire at their end date; where it cannot, put the end date on the checklist line.

• Then: Add it to the monthly reconciliation

Step

Add it to the monthly reconciliation

Within 3 working days of each month end by the pack's default, take a complete account extract from the service, local and shared accounts included, and match every account to a current person in the HR record or the sponsor register. A service whose extract did not arrive is recorded as not reconciled, never as a month with no findings.

• Then: Does any account match nobody, or have no named owner?

Decision

Does any account match nobody, or have no named owner?

An orphaned account matches no current person in the HR record or the sponsor register, or is a shared account with no named owner. The first full user list of a service often finds some: in the pack's example a booking portal's first list found a former employee's account and an ownerless shared login.

• Yes, or not known: Disable each within 1 working day and raise a finding
• No: Keep it in discovery, the leaver checklist and the review

Step

Disable each within 1 working day and raise a finding

Disable each orphaned account within 1 working day of finding it by the pack's default, and ask the system owner to name an owner or confirm deletion. A shared account stays only where the service cannot work without one, with a named owner and the system owner's approval. Raise each orphaned account with the access review as a finding.

• Then: Keep it in discovery, the leaver checklist and the review

Outcome

Keep it in discovery, the leaver checklist and the review

The service now has an owner, a named person who removes its accounts, and a monthly check that catches what the leaver process missed. If it is in scope for the periodic access review, add it to that review's system inventory too, as the pack's example did for its booking portal.