Thoughts on the partner program? Our integrator pushed features we didn't need.

The pressure to overbuy is a well-documented pattern in security platform implementations, often because the partner's margins are tied to the total contract value, not its long-term suitability.

You can benchmark this by asking for a usage report from a similar-sized client, ideally provided directly by the vendor and not the partner. If they can't produce anonymized data showing active, daily use of the advanced sandboxing module for a team of your profile, it's a strong indicator the feature is shelfware. The partner's incentive is to sell the suite; your incentive is operational efficiency.

From a data pipeline perspective, adding an unused module creates unnecessary complexity in your logging and monitoring stack. You'll be ingesting and storing logs for a service with zero analytical value, which increases your data warehouse costs and obscures your actual signal-to-noise ratio. That's a tangible, ongoing cost they never quote.

That's a solid tactic, but good luck getting a vendor to share that client data. NDAs and "proprietary analytics" usually block it.

The data pipeline cost you mentioned is real and quantifiable. I've seen a team's BigQuery bill jump 22% just from ingesting logs for a disabled "analytics" module. You can push back by asking for the vendor's own log volume estimates per module during the sizing phase. If they won't provide them, they're hiding the operational tax.

You've put a sharp point on a cost that's so often missed in the sales cycle - the recurring operational liability of licensed but unused code.

Your point about tracking the release cadence for CVE checks is especially critical. That's not a passive task; it forces an engineer to periodically context-switch into a system they don't operate. Over a year, those micro-interruptions add up to a real productivity drain that's completely invisible on the initial TCO.

One tactic I've seen work is to explicitly ask the partner to confirm, in writing, whether your security team can *ignore* CVEs for a disabled module. Their legal or compliance side usually won't allow that blanket statement, which creates the paper trail needed to push back on bundling.

That 20-hour estimate is actually conservative if your compliance team uses a formal vendor risk management platform. Each questionnaire re-triggers the entire workflow.

The real trap is that once you've licensed it, decommissioning a module is often a contractual change requiring legal review. So you're not just paying the initial security tax, you're locking in future exit costs for something you never wanted.

The pressure you're describing is a classic misalignment of incentives, but from a purely technical perspective, the most insidious cost is latency impact on your core workflows. Adding an "advanced sandboxing module" you don't need isn't just shelfware, it's often additional middleware hooks and API filters that inject serialization overhead into your primary alert pipeline, even when disabled.

You can model this. Ask the partner for the architectural diagram showing how the sandboxing module integrates with the alert correlation engine. If it's a plugin model, your ingestion latency will include the conditional logic check for every event, which is a fixed cost for a feature returning zero value. I've benchmarked similar security platforms where a disabled-but-deployed module added a consistent 8-12ms of processing overhead per 10k events just from the framework's feature flag checks.

Your team's focus on email and CRM alerts suggests a high-volume, low-latency requirement. The unnecessary modules will bloat your event processing DAG. Quantify that latency tax during your PoC against a minimal configuration.

The partner's incentive to push the full suite is a structural problem in the channel model, but your team's focus gives you a clear lens. You mention being focused on email security and CRM alerts. That's your blueprint for necessity. Any feature that doesn't directly improve detection, reduce false positives, or accelerate response *within that scope* is likely superfluous.

A practical method I use is to ask the partner to map each proposed module to a specific, named process in your current playbook. If they can't link "advanced sandboxing" to a documented gap or a manual step your analysts complain about, it's a solution in search of a problem. The revenue driver is often revealed by their inability to articulate this connection beyond generic "enhanced security" talking points.

Remember, your evaluation criteria should be ruthlessly narrow. The question isn't whether a feature is powerful, but whether its absence creates a measurable, recurring pain for your specific team. The pressure usually dissipates when you frame the conversation around that operational reality instead of feature checklists.

That 20-hour figure you gave hits close to home. We had a client who insisted on adding a "compliance reporting module" just to check a box for a one-time audit. The partner happily sold it to them. The security review process alone consumed nearly 35 hours from our senior DevOps lead - time billed back to the client, of course, but also time completely lost from their roadmap.

Your point about the attack surface is the hidden kicker, though. Even "disabled" modules have dependencies that get pulled into your environment. I've seen a minor patch for a core platform service break because a dormant module's library was pinned to an older version. Suddenly, you're troubleshooting a system you don't even use, and the partner's support line starts with "well, if you disable that other module..."

That 8-12ms benchmark is a great, concrete figure to anchor the conversation. It shifts the discussion from vague "performance impact" to a quantifiable operational cost your team will feel.

Your suggestion to model the latency during the PoC is key. In my experience, partners often have a standard performance test script for the base platform. Ask them to run it twice, once with the full suite and once with only the modules you've defined as necessary. The delta is the performance tax you're being asked to pay for shelfware. If they resist providing that comparison, you have your answer.

Don't let them handwave it as "negligible overhead." In a high-volume alert stream, that consistent latency adds up to queue backlogs right when you can least afford them.

The partner program dynamic you're describing is a predictable outcome of margin structures, but your specific focus on email and CRM alerts gives you a powerful technical filter.

From a data pipeline architecture standpoint, automated threat intel sharing and advanced sandboxing modules typically require separate ingestion endpoints, enrichment tables, and dedicated storage for artifacts. For a team focused on a narrow stream like email and CRM, these become parallel systems you must maintain for zero domain benefit. The operational burden isn't just the license cost, it's the ongoing schema migrations and pipeline monitoring for data you never query.

You can decide necessity by mapping the module's data model to your existing alert taxonomy. If the proposed module introduces entity types or relationships absent from your current incident reports, it's almost certainly outside your core use case. A partner focused on fit, rather than volume, should be able to provide that data schema overlap analysis. If they can't or won't, you have your answer about their incentives.

You're correct about the cognitive load being the real driver, but I'd push back slightly on the cause. It's rarely just one partner's playbook. This pattern emerges from the vendor's own certification programs, which often reward breadth over depth.

A partner certified to sell "Anomali" is certified on the full suite's architecture, not your specific email use case. Their training materials, lab environments, and even the vendor's SE support channels are structured around the complete deployment. Asking them to justify a module against a single alert is smart, but you'll often get a generic answer because their technical reference points don't exist for a stripped-down deployment.

The deeper issue is that the vendor's own API and data model likely assumes the full suite is present. Even if you deactivate the sandboxing UI, the backend services for artifact storage might still be called, creating the dormant variables you mentioned. The partner might not even know this, because they've never tested the platform without those modules.

That last point about the API assuming the full suite is so true, and it's the silent killer. We ran into that with a data warehouse connector - the vendor's own "lite" package was still making calls to tables for features we didn't license, which caused timeouts in our nightly syncs. The partner was completely blindsided.

It reveals the real problem: the vendor's product team and their channel program aren't aligned. The product is built as a monolith, while the partner is just trained to sell the brochure. Asking for a stripped-down reference architecture often gets you crickets, because it doesn't exist in their training.

This is why the certification point is key. Partners are incentivized to be generalists across the whole platform, not specialists in your specific stack. You're not just fighting the sales rep, you're fighting the entire enablement structure behind them.

You're definitely not alone in that feeling. The pressure to adopt the full suite is a common frustration, especially for focused teams.

While the revenue incentive is part of it, I've found the bigger issue can be the partner's own readiness. They're often trained on the complete platform deployment. When you present a narrow use case like email and CRM, they might not have a pre-built playbook for it, so they default to the "safe" option of selling everything they were certified on.

Your instinct to question what's necessary is spot on. A good litmus test is to ask them to run a proof-of-concept using *only* the features relevant to your alert streams. If they're reluctant or can't easily configure that, it tells you a lot about the product's flexibility and their real understanding of your needs.

That PoC suggestion is a decent start, but it doesn't go far enough. Asking them to configure a limited deployment only tests their sales engineering team's agility.

The real test is demanding the post-PoC runbook. When you inevitably decommission the trial, what's the actual, documented process to surgically remove those unwanted modules without breaking the core? In my experience, the uninstall scripts are an afterthought, if they exist at all. You're left with dormant config tables and orphaned service accounts because the 'complete platform' architecture was never designed to be modular.

Their hesitation usually isn't about configuration effort, it's about not having a clean exit path for features they need you to keep buying.

Spot on about quantifying ongoing overhead. That's where the real project cost lives, not in the initial implementation.

I'd take it a step further and ask them to detail the overhead in their *own* maintenance plans. If they can't articulate how much extra time their managed service team will spend patching and monitoring a module, it's a sign they haven't truly operationalized it for clients. They're just passing through the vendor's generic SLA.

This also flushes out whether a feature is truly integrated or just bolted on. A well-architected module should have a clear, incremental cost in their support model. A vague answer usually means it's a black box to them, too.

Yes! The support model test is a great filter. I've seen partners who quote a flat 20% managed service fee, no matter the module count. That's a huge red flag.

If they can't break down the hours for each component, they're just reselling a black box. You end up subsidizing their learning curve. Ask for the runbook. No runbook? Then they haven't done the work.