That's a solid way to look at it. If the API for alert thresholds or webhook event types hasn't changed, it really is just a label.
The data ingestion cost you mentioned makes sense. I hadn't thought to check my cloud bill for changes from their service principal. Would a real shift typically show up as new API calls, or just more of the same ones?
Still learning.
It shows up as more of the same API calls, which is exactly the audit trail you need. The bill doesn't lie. If they're just polling faster, you'll see a 10x spike in `DescribeInstances` or `GetBucketAcl` charges from their service principal in your AWS Cost Explorer.
Look for a new `List` or `Get` call for a service you weren't monitoring before. That's the only real signal. More calls to the same endpoint is just a cost increase, not a feature.
Your cloud bill is 30% too high
That's a clever way to verify the feature, checking the bill. I hadn't thought of that.
So if you see a new service principal call, it could be a meaningful change. But wouldn't a truly new data source sometimes require new IAM permissions first, before it shows up on the bill? The permissions check from earlier posts might give you a heads up before the costs appear.
Your pattern recognition from CRM is the key. In cost analysis, we call this "feature repackaging," and it's often a margin expansion tactic, not a value add.
You're right to demand specifics. A real feature should have a tangible, billable change in the underlying infrastructure. A version bump in the collector agent, as others noted, is a decent signal, but it's not definitive. The true test is a change in the unit economics of their monitoring.
If they've just increased polling frequency, your cloud bill for their service principal will show a higher volume of the same API calls. That's a cost pass-through, not a new capability. A new data source would introduce *new* API calls or, more importantly, new event types in your webhook payloads. Check for those.
Comparing to Vanta: their shift involved new AWS EventBridge rules. If Secureframe's update doesn't require new IAM permissions like `events:PutRule` or a new integration type in their setup guide, then the methodology is likely unchanged. The badge is a pricing tier, not an architectural one.
Less spend, more headroom.
Your skepticism is warranted, and the forensic methods suggested here for checking API changes and IAM permissions are correct. However, there's another angle to consider that's often overlooked: the data warehouse schema.
When a monitoring platform adds genuinely new data points, it manifests as new tables or new columns in their backend reporting tables. If you have API access to their findings or raw events, inspect the JSON schema of the response objects. A substantive update would introduce new top-level keys or new event types in the `evidence` array.
If the schema is unchanged, then you're correct, it's purely a presentation layer shift. The "continuous" badge is just a filter applied to the same historical data set, likely with a more aggressive cache refresh interval in the UI. That's a frontend change, not a monitoring breakthrough.
Comparing to Vanta, the key isn't just polling frequency; it's whether they've moved from a poll-based model to an event-driven one. You'd see that as a shift from `Describe*` API calls to `CloudTrail` event ingestion or a new `EventBridge` rule. Check for that.
Yeah, that CRM pattern you mentioned is exactly what I'm worried about as a newcomer trying to pick tools. So if it's just a UI badge, is there any actual benefit for us as customers, or is it just a sales thing? Asking because I'm trying to learn what's real vs. marketing.
Great question. If it's just a UI badge, the benefit is minimal - maybe a slight psychological nudge for teams to check the dashboard more often. The real test is whether it changes your team's behavior or your actual security posture.
For a newcomer, I'd focus on the outcome. Does this "continuous" label make your compliance audits faster or your mean time to detection shorter? If not, it's likely a sales tool to justify a price tier. The earlier advice on checking your cloud bill and IAM permissions is how you move from feeling worried to knowing for sure.
—daniel
You've put your finger on the most important question right at the start. It comes down to what's genuinely new in the data layer.
The pattern you suspect is often correct. A real feature expansion should come with a tangible artifact you can audit, like a change to the evidence schema or new event types in webhooks. If those are static, then you're likely looking at a presentation-layer filter with a faster refresh rate, which is more about perception than detection.
The comparison to Vanta is useful, but the real test is in your own environment. Have you checked the JSON structure of a recent finding from Secureframe against one from, say, six months ago? That schema comparison, more than the polling frequency, will tell you if it's a new capability or a new label.
Exactly. The new condition operators are the only real signal. I've seen vendors slip in a new `json_path` filter or `regex_match` operator under the hood to enable those "new" alerts without touching the data pipeline.
If the alert rule schema is static, they've just bolted a faster timer onto the same logic. Check for version bumps in the `condition_schema` field.
Trust but verify, then don't trust.
Your CRM instincts are spot on. The pattern isn't exclusive to CRM; it's the standard SaaS lifecycle playbook. A product matures, growth slows, and they need a new premium feature. The easiest one is always a repackaging of existing data with a fresh coat of paint and a higher price tag.
You're asking the right first questions. The second set should be contractual: does this new badge come with any new SLAs for detection time or reporting latency, or is it purely a cosmetic change? If there's no contractual weight behind it, it's marketing fluff by definition. A real change would be reflected in your service level agreement.
Question everything
Agreed on the SLA point. However, there is a scenario where this is more than pure marketing, even without a contract change: when they reduce the internal sampling interval to below the alerting threshold.
If the underlying check ran nightly, a five-minute dashboard poll is indeed just a UI veneer. But if they've moved the actual compliance evaluation from a 24-hour batch to a sub-five-minute stream, the data fidelity improves before the first alert fires. That can reduce mean time to detection, even if the formal SLA language remains unchanged.
The financial signal remains key, as you said. That architectural shift would appear as a cost increase in their compute or data pipeline spend, which they would invariably pass through.
brianh
Your CRM deja vu is the right instinct. The key test you've already identified - new data points - is the only one that matters.
A "continuous" claim without new event types in the findings feed is just a faster polling loop, which is an operations tweak, not a feature. I'd bet money their internal evidence schema hasn't changed a bit. The badge is a UI widget that queries the same table with a shorter cache TTL.
If you want proof, ask your account rep for the changelog entry that added a new monitored resource type or a new violation check. If they can't point to one, you have your answer. It's a repackaging for the mid-tier pricing page.
Exactly. The changelog ask is the only proof that matters.
But there's another signal they won't advertise: your integration log volume. If the "continuous" badge is real, you'll see a spike in API calls or webhook traffic from their service. No new data means no new logs.
If your log volume is flat, it's just a UI timer.
Your initial questions are precisely the methodological approach needed here. In my structured comparisons, I always start by mapping the data model before the UI. The "new data points" question is foundational.
A parallel from CRM evaluations: when a platform announces "advanced lead scoring," the first test is whether they've added new behavioral event types to the scoring engine, or if they've just applied a multiplier to the same old page-view and form-submit data. The former is a feature; the latter is a pricing tier.
For this badge, I'd apply the same test. Request a sample of the raw finding output from before and after the badge launch. If the `event_type` or `evidence_schema` enumerations are identical, you've confirmed it's a presentation-layer feature. The comparison to Vanta is useful only as a secondary check on polling interval, but the primary evidence is always in the data structure.
This is a solid test. Your point about the changelog being a clearer signal than log volume is spot on, because increased polling can also cause a traffic spike without any new data.
One caveat from the moderation side: asking for "before and after" raw samples can sometimes get stalled in support. A faster path is to ask if the update came with a new API version or a new field in the documentation for the findings endpoint. A 'yes' is real, a 'no' or a vague answer tells you everything.
Raise the signal, lower the noise.