To remove a customer’s leavers from your product reliably, you need a way for the customer’s own directory to tell your product who has left, and the standard way to do that is SCIM (System for Cross-domain Identity Management), which lets the customer’s identity system disable or delete accounts in your product automatically. Until you have that, removal depends on someone at the customer emailing your support team and someone on your side acting on it, which works for a handful of customers and becomes a promise you cannot keep as the list grows. The decision for a CTO is what removal time to commit to in writing, and whether the number you can honestly meet by hand is good enough for the next few contracts.
This post is for the CTO, founder or head of engineering at a small B2B SaaS company whose first large customer has written a line such as “users must be removed from the product within a set time after they leave our company” into a security questionnaire or a draft contract. It covers why the customer asks, how most small teams cope today, what automatic removal means in plain terms, how to decide what to promise, and what it costs in people-time.
Why does a large customer care what happens to the people who leave?
An employee who has left still has a login to every product the company bought, unless someone removes it. The customer’s security team treats each of those leftover accounts as a way in: a former employee, or anyone who obtains their credentials, could keep reading company data, and the company would have no record of why that access was still open. Removing leavers promptly is a standard control: it falls under the logical access criteria of the AICPA Trust Services Criteria used in SOC 2 audits, and under the access rights control in ISO/IEC 27001 Annex A, and auditors look for evidence of it. Our post on the joiner, mover and leaver process covers the same lifecycle from the customer’s side.
How does the request show up in questionnaires and contract drafts?
It usually arrives as one question on a vendor security questionnaire, such as how quickly your product removes access when a customer’s employee leaves, and sometimes as a clause in a security addendum with a fixed time. Our post on what security questionnaires ask about login covers where it sits among the other identity questions. The wording is short, but you are agreeing to a service level on a process your customer controls and you only partly see.
How do most small SaaS teams handle removal today?
Most start with a manual process. The customer’s administrator emails support or opens a ticket, someone on your team finds the user and deactivates it, and the administrator gets a confirmation. It is simple and it works while there are few customers and few leavers.
Where does manual removal break down?
It breaks in four places:
- Timing depends on people. An email sent on a Friday evening is not acted on until Monday, and your team cannot meet a four-hour commitment on a weekend.
- The customer’s administrator has to remember. The leaver process at the customer is often owned by HR and IT, and telling each vendor is the step most likely to be forgotten.
- You cannot show it was done. An auditor will want a list of removals with the date the customer asked and the date you acted, and a mailbox is a poor record.
- It scales with customers. Each new customer adds leavers every month, and every one of them is a task.
What will the customer’s auditor ask you to show?
Typically the date the person left, the date their access was removed, and evidence that the second came soon enough after the first. They may also ask for a periodic list of active accounts for the customer to compare against its own records, which is the idea behind a user access review.
What does automatic removal mean in plain terms?
Automatic removal means that when the customer’s identity system, such as Microsoft Entra ID or Okta, marks a person as having left, it sends your product a message and your product disables the account without anyone typing anything. The common standard for that message is SCIM, defined in RFC 7644, with the user data model in RFC 7643. In SCIM, a leaver is normally signalled either by an update that sets the user’s active attribute to false or by a delete request, and your product needs an endpoint that understands both.
Two things are worth knowing as a decision-maker. First, SCIM is something the customer switches on, and it needs a developer on your side to build the receiving endpoint or a managed service that provides one. Second, it is not necessarily instant, and providers differ. Microsoft Entra ID runs provisioning in cycles, so a departure can wait for the next cycle, while Okta generally sends a deactivation as soon as the change is made. The removal time you can promise is the customer’s sync delay plus your processing time, so read the provider documentation for the actual behavior before you write a number into a contract. Our comparison of just-in-time provisioning and SCIM explains why creating accounts at first login does not remove anyone.
What do you have to build or buy to receive that signal?
There are two routes. You can build the SCIM endpoint in your product, including authentication for the customer’s identity system, mapping to your user table, and handling of groups and edge cases such as re-hiring. Or you can put an identity layer in front of your product that provides it. Keycloak, the open-source identity server behind our identity management as a service, includes a native SCIM API that became supported in 26.8; it is inbound only, which suits receiving leavers from a customer directory. Two details matter for a multi-customer product: the SCIM setting is per realm, so you need to decide how each customer’s connector is scoped so it cannot touch other customers’ users, and disabling a user blocks new logins but does not by itself close sessions already open in your application, so the application needs to handle back-channel logout or check the account on each request. Our post on the Keycloak 26.8 SCIM API lists what it covers and what it does not, so check it against what your first customer’s provider sends.
How do you decide what to promise?
Start from what you can do reliably now and work outward.
What removal time can you meet by hand for your first customers?
Count honestly. If one person monitors the support inbox on business days, a next-business-day commitment is realistic and a four-hour one is not. Choose a time you can meet and prove, because a reviewer will test the promise and a missed short one counts against you. State whether the clock starts when the customer tells you or when the person left, since you only know the first.
When does the number of customers make manual removal a risk?
A rough test: if any contract commits you to hours instead of days, or if you cannot staff the inbox for the window you promised, manual handling will start to fail. The other trigger is a customer that mandates SCIM, which is common among larger buyers, as our post on how long it takes to become enterprise-ready on login discusses.
What does this cost the team, and how do you plan for it?
Building and maintaining SCIM yourself is a real project for the first version, plus ongoing time for each customer’s identity provider, because every provider interprets the standard slightly differently and your team will debug each one. Using a managed identity service shifts that to configuration and a monthly bill, and you still need time to test each customer’s setup. We would put it to the team as a choice between spending engineering time once and keeping it maintained, or paying for it to be run for you, and compare that against the support hours manual removal consumes. Our security page lists what we document about our own controls.
What should you settle with engineering before replying to the customer?
- How long does removal take today, from the moment support sees the request to the moment the account cannot sign in?
- Does disabling an account also end its active sessions and API keys, or only block the next login?
- Can you produce a record of each removal with a date?
- What happens to the person’s data and to content they own?
- Which of your customers’ identity providers support SCIM, and what is their sync interval?
- Who covers removals outside business hours, if the contract asks for it?
Write down the answers, choose a removal time you can defend, and reply with that number and the evidence you will provide.
Frequently asked questions
What is deprovisioning?
Deprovisioning is removing or disabling a person’s access to a system when they leave or change roles. For a SaaS product it usually means disabling the user’s account and ending their sessions.
Is SCIM required to meet a removal commitment?
No, but it is the practical way to meet a short one. Manual removal can satisfy a next-business-day commitment if you have a reliable process and a record.
Does single sign-on remove leavers automatically?
Partly. When a customer uses single sign-on and disables the person in its directory, that person can no longer log in through it, but their account and any existing sessions or API keys in your product may remain. SCIM is what removes or disables the account itself.
Who is responsible for telling you that someone left?
The customer. Your commitment should say how the customer notifies you and when your clock starts, so that you are not held to a time for a departure you were never told about.
What should the contract say?
That is a question for your lawyer, but engineering should supply the facts: the method of notification, the achievable time, and the evidence you can provide.