How do I price a security/compliance feature — bundled or upsell?

What to Bundle versus. What to Upsell

The mistake most teams make is treating "security" as one undifferentiated bucket and drawing the paywall line by tier convenience rather than by buyer psychology and cost structure. There are actually three distinct buckets, and the line between them is what determines whether your pricing helps or hurts you.

Bucket one — bundle into every paid tier. These are the controls a security reviewer expects to see checked "yes" without thinking about it. Encryption in transit (TLS 1.3) and at rest (AES-256) is table stakes; nobody pays extra for a lock on the front door. SSO through SAML 2.0 plus OIDC (so you cover both enterprise IdPs like Okta, Entra ID, and Ping, and consumer/Google Workspace flows) belongs here even though it is tempting to gate, because it is the single most-scrutinized item in mid-market and enterprise questionnaires. MFA enforcement, RBAC with at least a few meaningful roles (not just admin/non-admin), audit-log export with a 90-day retention floor, breached-password screening against known-compromised credential lists, and configurable session timeouts round out the set. The engineering cost of this bucket is a one-time build, typically a small single-digit percentage of platform R&D, and the ongoing marginal cost per customer is effectively zero. The payoff is that a well-built baseline passes the large majority of mid-market security questionnaires on the first pass, which is worth far more in cycle time than any add-on line item.

Bucket two — the legitimate Enterprise upsell. These are the capabilities that carry real, recurring per-customer cost or exist only to satisfy a regulated buyer. SOC 2 Type II and ISO 27001 require paid external auditors, continuous evidence collection, and staff time every single year. A HIPAA BAA exposes you to specific legal and operational obligations and is only relevant to healthcare-adjacent buyers. A GDPR DPA with granular sub-processor disclosure and data-residency guarantees implies regional infrastructure and legal overhead. FedRAMP Moderate or High is a multi-quarter, six-or-seven-figure undertaking that only public-sector buyers need. Customer-managed keys (BYOK) integrated with a customer's KMS, SCIM 2.0 for automated user lifecycle management, IP allowlisting, custom data residency across specific regions, audit retention measured in years with live streaming into Splunk, Datadog, or a customer SIEM, and a contractual security-review or incident-response SLA all impose genuine ongoing cost. Enterprise budgets are built to absorb these, and enterprise buyers do not read a premium on them as an insult — they read it as evidence you take the obligation seriously.

Bucket three — never behind a paywall, ever. This is the short, high-consequence list: SSO, MFA, audit logs, and basic encryption. Every one of these placed on the upsell side becomes a documented procurement objection and a scored zero on an evaluation grid. If your instinct is to gate SSO because "everyone does it and enterprises will pay," pause: the vendors who successfully gate SSO are almost all security-native products where access control *is* the value. For horizontal SaaS, gating SSO is the textbook self-inflicted wound.

The practical test for which bucket a feature belongs in is not "how much will someone pay for it" — it is "what does a buyer conclude about my product when they see it costs extra." If the conclusion is "reasonable, that's an advanced need," upsell it. If the conclusion is "so the cheap tier is insecure," bundle it.

The SSO Tax: Why Paywalling Baseline Security Backfires

The clearest cautionary pattern in SaaS pricing over the last few years is the "SSO tax" — the practice of locking single sign-on behind the most expensive tier, often at a multiple of the base price. It became notorious enough to spawn a public shaming site, sso.tax, that catalogs vendors who do it and the eye-watering markups involved. The site exists precisely because buyers, security teams, and IT admins came to see SSO-gating not as a pricing choice but as a security anti-pattern: SSO is how an organization centrally enforces offboarding, MFA, and access policy, so charging extra for it means charging extra for the ability to be secure at all. Public pressure from that catalog has pushed a number of well-known collaboration and productivity tools to move SSO down into lower tiers.

Understanding *why* it backfires mechanically matters more than knowing that it does. In a competitive evaluation, procurement builds a scoring grid. Every security capability the buyer cares about is a row; every vendor is a column; each cell gets a yes/no or a score. When you gate SSO, MFA, and audit logs, you have handed the buyer three rows where you score zero against a competitor who bundles them — and you have done it *before price is ever discussed*. In many mid-market deals, three missing baseline controls is functionally disqualifying, and you never even learn you lost on trust rather than features.

On the deals you do win, gating baseline security still costs you. Once procurement knows a security capability is a paid add-on, they treat it as negotiable scope: "We'll take it, but bundle the SSO tax into the base price." That conversation re-anchors the entire negotiation on what you're *withholding* rather than what you're *delivering*, and vendors negotiating from a position of "the base is missing something" concede deeper discounts than vendors whose base is complete. The premium you thought you'd capture gets clawed back as a concession, and you've spent negotiating capital doing it.

There is also a compounding, second-order cost that never shows up on the pricing page: renewal and expansion drag. When a customer's security or IT team discovers at renewal that the audit logs they now need for their own compliance program are paywalled, or that adding SSO requires a tier jump they can't justify, that friction becomes a retention risk. Bundled baseline security, by contrast, means procurement can lift the security questionnaire off the critical path entirely — which is the real reason vendors who bundle tend to expand into larger accounts faster: they've removed the single biggest source of deal friction from the front of the funnel.

The asymmetry is the whole argument. Gating baseline security offers a small, visible upside (an add-on line item some buyers pay) against a large, distributed downside (lost competitive deals, deeper discounts, slower expansion, brand exposure, renewal risk) that is spread across the funnel and the customer lifecycle where it's hard to attribute. The upside is easy to forecast in a spreadsheet; the downside is easy to ignore because it never lands in one visible number.

The Decision Framework

When you're staring at a specific feature and genuinely unsure which side of the line it belongs on, run a short, disciplined test rather than arguing from anecdote. Four questions settle almost every case.

1. Is your product security-native? If security *is* the product — an identity provider, a CDN/WAF, an endpoint or cloud security platform, a password manager — then granular security SKUs are expected and gating by depth of coverage is exactly how buyers expect to be charged. Deep packet inspection tiers, per-seat vault policies, or advanced threat-detection modules are the value ladder itself. If your product is horizontal (CRM, analytics, project management, collaboration, billing, HR), you inherit *none* of that license, and you should be extremely reluctant to gate anything a security reviewer treats as baseline.

2. Will this feature appear on a procurement scoring grid? SSO, MFA, audit logging, encryption, RBAC, and password policy all reliably do. If a feature shows up as a scored row in evaluations and you are not security-native, gating it is a self-inflicted zero. Bundle it.

3. Does the feature impose a meaningful recurring cost per customer? Annual external audits, regional infrastructure to satisfy data residency, dedicated key-management integrations, contractual SLAs backed by staffed on-call, and per-customer legal exposure (a BAA) all cost real money every year. Self-serve SAML configuration or a checkbox that enforces MFA does not. If the cost is meaningful and per-customer, you have a defensible upsell. If it's a one-time build with near-zero marginal cost, bundle it.

4. Would gating this feature plausibly get you listed on sso.tax or its equivalent in a buyer's memory? If the honest answer is yes, the brand cost outweighs any premium you'd capture. Bundle it.

Tally the answers. If three or four of these point toward "bundle," push the feature into the lowest paid tier without agonizing. If three or four point toward "gate" — you're security-native, the feature never appears as a baseline row, it carries real recurring cost, and no reasonable buyer would call it a tax — you have a legitimate Enterprise upsell you can price with confidence.

A useful mental shortcut layered on top of the four questions: bundle everything that makes a buyer *trust* you, and charge for everything that makes a buyer's *specific regulatory or scale situation* your operational problem. Trust is a growth lever; regulatory heavy lifting is a cost you're entitled to recover.

Pricing the Legitimate Upsells

Once you've correctly identified the features that belong on the upsell side, you still have to price them, and there are a few durable rules of thumb that hold up better than a single magic number.

Price advanced security as part of an Enterprise tier, not as an à la carte menu of security toggles. Buyers accept "Enterprise includes SSO SCIM provisioning, BYOK, custom residency, a BAA, and a security-review SLA, priced on a quote" far more readily than a checkout page where each control has its own price tag. A menu of individually-priced security switches reads as nickel-and-diming a company's safety; a coherent Enterprise tier reads as a different class of relationship. When you do expose an explicit add-on, make it a bundle with a clear identity ("Compliance Pack" or "Enterprise Security & Governance") rather than a loose collection of toggles.

Anchor the premium to cost recovery plus segment willingness-to-pay, not to a percentage pulled from the air. A common practitioner range for an advanced compliance or security package is a meaningful uplift on the base subscription — often in the neighborhood of ten to thirty percent of contract value for a mid-market account moving to Enterprise, and more when it includes genuinely expensive obligations like FedRAMP or heavy data-residency guarantees. Treat those ranges as starting points to test, not laws. The honest inputs are: your actual annual audit and infrastructure cost divided across the accounts that need it, plus what that segment's budget can absorb, plus a margin. If a single regulated buyer is asking you to stand up a HIPAA program or a new region, it is entirely reasonable for that first customer to fund a large share of the build.

Make certifications a proof asset, not a SKU. The subtle but important move is to stop selling "SOC 2" as a thing a customer buys and start treating the *report* as evidence you provide. You are not charging for the PDF; the PDF is free to any qualified prospect under NDA. What the Enterprise tier buys is the surrounding capability — the BAA, the residency, the SLA, the provisioning automation — that the certified posture enables. Selling the certificate itself invites the accurate objection that the control was already in your scope (per the AICPA's own definition of what SOC 2 Type II covers), so you're charging for something you already do.

Preserve the ability to add SKUs later, and be cautious about removing them. Pricing structure is asymmetric over time. You can almost always *introduce* a new premium security SKU — BYOK, a new region, FedRAMP — when a budgeted buyer asks for it, and the market treats that as natural product expansion. Retreating from a paywall after procurement across your customer base has been told it exists is far harder: it signals weakness, and the customers who already paid the "tax" become vocal detractors. So when in doubt, bundle the baseline now (you can't easily un-ring the bell of a bad paywall) and *add* premium SKUs later from a position of strength.

Watch the discount interaction. Whatever premium you set on advanced security, model how it behaves under discounting. If your enterprise deals routinely get 20-40% discounts, a security add-on priced as a separate line item often gets discounted away first because it's the easiest concession to make. Building the advanced security value into the tier price, rather than as a strippable line item, protects it from becoming the first thing sacrificed in the deal room.

Merchandising Security as Trust, Not a SKU

How you *present* security shapes revenue as much as where you draw the price line. The dominant 2026 pattern is the Trust Center: a self-serve page where prospects can see your certifications, security posture, sub-processors, and compliance documents, and request gated artifacts (like the SOC 2 Type II report) under NDA with a click. Products like Vanta, Drata, and SafeBase have institutionalized this, turning security from a slow email-and-questionnaire dance into a self-serve credibility asset. A buyer who can validate your posture in five minutes on a Trust Center never generates the RFP friction that a buyer waiting three days for a questionnaire response does. In many mid-market evaluations, the *absence* of a Trust Center is now itself a flag.

The strategic reframe is this: baseline security bundled into every tier plus a public Trust Center converts security from a cost center and a sales bottleneck into a differentiator. Instead of "buy the SOC 2 add-on," your motion becomes "we're SOC 2 Type II and ISO 27001 — here's the Trust Center, grab the report under NDA." That posture *removes* the questionnaire from the critical path, which is worth more in cycle-time and win-rate than any add-on revenue you'd extract by gating it.

There's a sales-enablement dimension too. When baseline security is bundled and documented, your reps stop losing days re-answering the same security questionnaire fields and stop routing every "do you support SSO?" question through a solutions engineer. That compression — fewer questionnaire revision cycles, fewer back-and-forths — quietly shortens sales cycles across the whole funnel. Merchandising security well is partly a pricing decision and partly an operational one: the Trust Center and a complete bundled baseline are what let the deal move fast.

Finally, be honest and precise in how you describe compliance. Never imply a certification you don't hold, never conflate SOC 2 Type I with Type II, and never present "in progress" as "certified." Security buyers verify, and a single overstatement discovered during due diligence poisons the entire relationship. The credibility you're building is the whole point of bundling security as a trust asset; misrepresenting it destroys the very thing that makes the strategy work.

A Worked Example: Mid-Market SaaS at Scale

Make the asymmetry concrete. Imagine a horizontal CRM doing roughly $30M ARR, weighing whether to introduce an SSO add-on priced at, say, $15 per seat per month — an uplift of a few percent of ACV on its typical Pro-tier deals. The pricing team builds a forecast and it looks great: assume a healthy attach rate on Pro deals at full price, and the model shows a clean seven-figure or high-six-figure ARR bump. On the pricing page, the upside is right there in one number.

Now price in what the forecast conveniently leaves out. First, competitive close rate: on every deal where the next vendor bundles SSO, you've handed procurement a scored zero and a reason to prefer the competitor before price comes up — some meaningful share of those competitive deals flip away from you, and at real pipeline volume that lost ARR can exceed the entire add-on upside on its own. Second, discount depth: on the deals you still win, procurement uses the "SSO tax" as a lever, and you concede deeper discounts than you otherwise would — a few points of extra discount across a year of bookings is real money. Third, brand and top-of-funnel: gating SSO on a horizontal product is exactly the behavior that gets a vendor added to public "SSO tax" lists and mentioned in buyer communities, with a diffuse but real drag on inbound conversion. Fourth, renewal: some year-two churn traces back to security or IT teams hitting the paywall when their own compliance needs grow.

Stack those four effects and the "obvious" few-percent ACV uplift frequently inverts into a net *negative* on total revenue. The upside was concentrated and visible; the downside was distributed across new-business win rate, discount depth, top-of-funnel conversion, and renewal — four places nobody attributes back to the pricing-page decision. That is the canonical shape of the mistake: the gain is easy to see and the losses are easy to miss, which is precisely why so many teams make it.

The counter-scenario is worth stating fairly, because there are narrow cases where gating baseline security is defensible. If you are a security-native vendor, granular SKUs are expected and this whole analysis flips. If you sell exclusively into large enterprises with explicit line-item security budgets and long, deliberate cycles — and you have *no* velocity mid-market motion where friction compounds — the procurement leverage matters less. And very early, pre-product-market-fit companies sometimes use a security paywall deliberately as a willingness-to-pay probe to learn tier elasticity before locking structure. Outside those three cases — horizontal product, mid-market or PLG-influenced funnel, competitive RFPs — the bear case fails, and the worked example above is the reason. Bundle the baseline, price the genuinely advanced controls into a coherent Enterprise tier, merchandise the whole posture through a Trust Center, and reserve your pricing power for the capabilities enterprise buyers actually expect to pay for.

FAQ

What is the difference between bundled and upsell security features? Bundled security features are the baseline protections included in every paid tier — TLS 1.3 and AES-256 encryption, SSO, MFA, RBAC, breached-password screening, and audit-log export. They cost you a one-time build and near-zero per-customer, and they're what a security reviewer expects to see by default. Upsell features are advanced, cost-bearing capabilities that only some buyers need: SOC 2 Type II and ISO 27001 delivered via a trust portal, a HIPAA BAA, a GDPR DPA, FedRAMP, BYOK, SCIM provisioning, custom data residency, long-horizon audit retention with SIEM streaming, and security SLAs. The dividing line is whether the feature builds baseline trust (bundle it) or imposes real recurring cost and serves a specific regulatory or scale need (upsell it).

How do I decide which security features to bundle versus upsell? Run the four-question test: (1) Is your product security-native? If not, be reluctant to gate anything baseline. (2) Does the feature appear on a procurement scoring grid — SSO, MFA, audit logs, encryption? If yes, bundle it. (3) Does it impose meaningful recurring per-customer cost like annual audits, regional infrastructure, or a staffed SLA? If yes, it's a legitimate upsell. (4) Would gating it plausibly earn you an "SSO tax" reputation? If yes, bundle it. Three or four "bundle" answers means push it into the lowest paid tier; three or four "gate" answers means you have a defensible Enterprise upsell.

Can I charge extra for compliance certifications like SOC 2 or HIPAA? Yes, but charge for the *capability*, not the certificate. The SOC 2 Type II report itself should be free to qualified prospects under NDA through your Trust Center — charging for a PDF invites the accurate objection that the control was already in your scope. What the Enterprise tier legitimately buys is the surrounding obligation: the HIPAA BAA and its legal exposure, custom data residency, the DPA with sub-processor controls, provisioning automation, and a security-review SLA. Those carry ongoing cost and are only needed by regulated or large buyers, so pricing them into an Enterprise tier is fair and expected.

What happens if I paywall baseline security like SSO? You create the "SSO tax" problem. In competitive evaluations, gated SSO, MFA, and audit logs become scored zeros on a procurement grid — often functionally disqualifying you before price is discussed. On deals you still win, procurement weaponizes the paywall to negotiate deeper discounts. You risk being cataloged on public shaming lists like sso.tax, which drags on top-of-funnel conversion. And you plant a renewal-time landmine for when a customer's security team needs the paywalled capability for their own compliance. The small, visible add-on revenue is usually dwarfed by these distributed, hard-to-attribute losses.

How much should I charge for advanced security upsells? There's no universal number, but a common starting range for an advanced compliance or security package is roughly a ten-to-thirty-percent uplift on contract value for a mid-market account moving to Enterprise, and more when it includes expensive obligations like FedRAMP or dedicated data residency. Anchor the price to your actual recurring cost (annual audits, regional infrastructure, key management, staffed SLAs) divided across the accounts that need it, plus what that segment's budget can absorb, plus margin. Build the value into a coherent Enterprise tier rather than a menu of individually-priced toggles, so it doesn't get discounted away as the first easy concession in the deal room.

Should I use a Trust Center, and does it affect pricing? Yes — a Trust Center (via tools like Vanta, Drata, or SafeBase) has become an expected pattern, and its absence is a flag in many mid-market evaluations. It converts security from a slow questionnaire bottleneck into a self-serve credibility asset: prospects verify your posture and request gated artifacts under NDA in minutes. That removes the security questionnaire from the critical path, shortens sales cycles, and reduces the SE and questionnaire-revision overhead per deal. It also reinforces the correct pricing posture — security as a trust differentiator you bundle, with pricing power reserved for the genuinely advanced controls, rather than a paywall you monetize.

Sources

• sso.tax — the public catalog of vendors charging a premium for single sign-on and the markups involved: https://sso.tax
• AICPA — what SOC 2 (including Type II) actually covers, the authoritative reference for scope: https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
• ISO/IEC 27001 — the international standard for information security management systems: https://www.iso.org/standard/27001
• NIST Cybersecurity Framework — reference framework for assessing and communicating security posture: https://www.nist.gov/cyberframework
• FedRAMP — the U.S. government program governing cloud security authorization (Moderate/High): https://www.fedramp.gov/
• U.S. Department of Health & Human Services — HIPAA rules and Business Associate obligations: https://www.hhs.gov/hipaa/index.html
• Vanta — trust management and Trust Center platform documenting the self-serve security-proof pattern: https://www.vanta.com/

Related on PULSE

• [How do I structure 3 vs 4 vs 5 pricing tiers?](/knowledge/q77)
• [How do I handle a security review that's threatening to kill a deal?](/knowledge/q71)
• [How do I run a security review process with limited resources?](/knowledge/q189)
• [How do I design a 3-tier SaaS structure when competitor tiers blur?](/knowledge/q339)
• [Public vs private SaaS pricing: which should I use?](/knowledge/q1106)
• [How do I build a federal/public-sector sales motion?](/knowledge/q95)