In the rush to automate SOC 2 or ISO 27001, procurement teams often fixate on the platform fee. They negotiate the base price down from $15,000 to $10,000 and declare victory. But they miss the line item that will eventually blow the budget: the definition of a "Billable User."
Most compliance automation platforms price based on the number of employees. It seems simple: you have 50 employees, you pay for 50 seats. But in the context of security compliance, "employee" is a fluid term. The technical reality of how these platforms ingest data often conflicts with the HR reality of who works for you.
The Disconnect: HRIS vs. Identity Provider
The core friction comes from where the platform pulls its "truth." If you connect your HRIS (like Rippling or BambooHR), the platform sees your payroll headcount. But if you connect your Identity Provider (like Google Workspace or Okta), it sees every account that can log in.
This distinction is critical. Your Google Workspace likely includes:
- Contractors & Freelancers: They aren't on payroll, but they have email addresses.
- Service Accounts:
[email protected],[email protected],[email protected]. - Test Users: Dummy accounts created by QA for testing production flows.
- Board Members & Investors: Often given courtesy accounts but never log in.
To a compliance automation tool, these look like "unmonitored humans." The platform flags them as security risks because they haven't completed security awareness training or installed the endpoint agent. To clear the flag, you have to "monitor" them. And the moment you monitor them, they become billable.
The "Active User" Fallacy
A common rebuttal during sales calls is, "We only charge for active users." This sounds fair, but you must clarify what "active" means. In many contracts, "active" doesn't mean "logged into the compliance platform." It means "active in your systems."
If a contractor logs into your Jira instance once to file a ticket, the integration detects an active account. The compliance platform then demands evidence for that user. If you want to exclude them from the audit scope, you often have to mark them as "Out of Scope" in the platform. Some vendors allow this for free; others count "Out of Scope" users towards your total tier because the platform is still processing their metadata.
The Contractor Clause
Review your contract for the "Contractor Ratio." Some vendors allow a certain percentage of non-employee users for free (e.g., up to 10% of total headcount). Others charge full price for every contractor, effectively penalizing you for using a flexible workforce.
How to Protect Your Budget
When evaluating security compliance automation software, you need to ask three specific questions during the demo phase, not after the contract is signed:
- "How do you treat service accounts?"
Demand a written confirmation thatsupport@andadmin@generic accounts are excluded from billing, provided they are not tied to a specific human identity. - "What is the mechanism for marking users out-of-scope?"
Ask to see the UI. Is it a simple toggle? Does it require auditor approval? Does marking a user out-of-scope remove them from the billable count immediately, or only at renewal? - "Do you bill based on the HRIS list or the IdP list?"
If they bill based on IdP (Okta/Google), calculate your "true" user count now. It is likely 20% higher than your HR headcount.
The goal of automation is efficiency, not paying a "compliance tax" on every email address in your domain. By defining "User" strictly in the contract—tied to payroll status rather than system existence—you can prevent the scope creep that turns a $10,000 tool into a $20,000 headache.