Connector economics, modules that meter on their own units, and the scoping error of licensing an organization instead of a team. Three knowledge checks along the way, and 3 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 3 times in the session the frame splits and a senior licensing analyst gives the view from inside real ServiceNow negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session twenty, and this one closes module four with the specialist estate, SecOps and IRM, which are the products where everything you have learned about counting people stops being reliable. And I want to be honest about why these two are hard. They are not bought by the platform team. They are bought by the security director and the chief risk officer, funded from a different budget, evaluated on completely different criteria, and by the time the platform team hears the numbers the numbers are already in a quote. Which means the specialist estate is where the platform wide instinct fails hardest, because the units are genuinely different and the people negotiating them have never been through modules one to three. There is also a line item in here that I have watched cost organisations six figures without anybody in the building knowing it existed. Three checks, homework, let's go.
Five objectives. First, price a connector, which means knowing the allowance in your edition, what an overage actually costs, and why a two way integration can consume two of them. Second, split the modules, because Security Incident Response and Vulnerability Response license independently and serve genuinely different teams whatever the bundle slide implies. Third, count fulfilled users honestly, active analysts and remediators rather than view only reporting consumers, and that distinction matters more here than anywhere else because the list price is five figures per person per year. Fourth, map GRC to IRM, because if your contract still carries prior era module names then somebody is going to map them to current packaging at your next renewal, and that mapping is a repricing. And fifth, scope to the team rather than to the organisation, because twenty five to forty percent of licensed risk module access sat with people who never once opened the module.
Four numbers. Fifteen to thirty percent, the share of the SecOps line driven by connector add ons, most of them deployed during proofs of concept with the contract never updating afterwards. Twenty to forty thousand dollars, the annual overage per connector above your edition's allowance, and that is per connector, per year, on something an engineer can stand up in an afternoon. Five of ten, the deals where Security Incident Response was bundled with Vulnerability Response and only one of the two was actually needed. And twenty five to forty percent, licensed risk module access sitting with people who never opened the module, because the entitlement got scoped to the organisation rather than to the team. Now the note underneath, which is the framing for the session. This is where the platform wide instinct fails hardest, because a per user assumption carried over from the fulfiller estate can be wrong by a wide margin, and it can be wrong in either direction.
Guest analyst clip. The single most avoidable finding I have ever delivered was a connector count. Financial services customer, good security team, genuinely competent people, and they had built out their SecOps integrations enthusiastically over about two years. Vulnerability scanners, endpoint tooling, threat feeds, a couple of internal systems. Nine connectors on an allowance of six. And when I asked who owned the connector count, the answer was that nobody had any idea there was a connector count. It was in their contract. It had always been in their contract. But the contract lived with procurement, and the people building integrations were security engineers whose entire job was to get data into the platform, and getting data into the platform is exactly what they had done, well. Two of those nine were bidirectional, which under their counting rule consumed two of the allowance each. So the real number was eleven against six. Five over, at somewhere between twenty and forty thousand a year each. What makes this the most avoidable finding I have ever delivered is the fix. It is a list. Somebody keeps a list of deployed connectors, checks it quarterly against the contractual allowance, and this entire category of exposure disappears. That is it. That is the whole control.
Somebody keeps a list and checks it quarterly. And notice how the exposure got built, because the security engineers were doing their job correctly and the contract was sitting with people who were not in the integration conversation. That is the same structural gap we found with roles in session eleven and configuration items in session seventeen. Now the modules themselves.
Four modules and the list prices, and I give you these to calibrate rather than to quote back at anybody. Vulnerability Response, which serves the remediators working findings through to closure, roughly eleven to twenty three thousand dollars per fulfilled user per year across the editions. Security Incident Response, for the SOC analysts responding to security incidents, roughly eleven and a half to twenty four and a half thousand. Threat Intelligence, for threat hunters and intelligence analysts, roughly fourteen to twenty and a half thousand. And Now Assist for Security, the generative AI layer, sold as a separate SKU at roughly four and a half to six and a half thousand, with discounts of ten to forty percent depending on the line. Now the note, and it is the important part of this slide. The metric counts active analysts, remediators, and threat hunters, and it excludes view only reporting consumers. At five figures per user, an over counted roster is expensive in a way that ITSM at a few hundred dollars a seat simply never is. Twenty extra names here is not a rounding error.
So, connectors properly, five points. The allowance is per edition, Standard includes three, Professional six, Enterprise unlimited, and that number is written in your contract and living in nobody's head. Overages are five figures each, twenty to forty thousand per connector per year, which makes one forgotten integration a serious line and five of them a genuine problem. Bidirectional can count twice, because an integration that both reads and writes may consume two of your allowance, and you want to check that counting rule before you build the seventh one, not after. They arrive during proofs of concept, which is where the fifteen to thirty percent comes from, because connectors get stood up in evaluation sprints and hackathon weeks and the contract never updates to match. And they are audited at renewal, which means ServiceNow compares your deployed roster against your contract as a matter of routine. This is found, not volunteered, and by the time it is found you have no leverage over it at all.
Knowledge check one. You hold a Professional edition with six connectors. Your team has deployed nine, two of them bidirectional. What is the likely exposure? A, three connectors over, at overage rates. B, potentially five over, if the bidirectional pair counts as four. C, none, connectors are unlimited on Professional. D, none until you formally request them. Pause here, and think about how the counting rule treats a two way integration.
The answer is B, potentially five over. Seven single connectors plus two bidirectional counted as two each gives you eleven against an allowance of six, so the naive arithmetic in answer A understates your exposure by a factor of nearly two. Answer C confuses Professional with Enterprise, which is an easy mistake and an expensive one. And answer D assumes that deployment is not consumption, which is precisely the same mistake as roles in session eleven and configuration items in session seventeen. Deployment is the trigger. Nobody has to approve it, request it, or even notice it for the meter to move. At twenty to forty thousand per connector per year, this single check is worth six figures, and a quarterly connector inventory removes the entire exposure. It is genuinely one of the highest return controls in this whole course.
Now the bundle, and the three module bundle carries an additional ten to twenty percent discount, which sounds good and only pays under one condition. Four cards. They license independently, each module owning a distinct workflow with its own team, and vulnerability remediation and incident response really are different jobs done by different people with different skills. The bundle pitch, which is that Security Incident Response gets quoted alongside Vulnerability Response in five of ten deals where only one of them was needed, with the discount used as the justification. The arithmetic, which is the whole slide, because a ten to twenty percent discount on three modules beats two modules only if the third module actually deploys, and a discount on an unneeded module is a discount on money you did not need to spend. And the test, which is to name the team, the workflow, and the go live date for each module, and treat any module missing all three as a candidate to drop rather than a candidate to discount. This is session three's bundle lesson for the third time, wearing SecOps clothing. The pattern recurs because it works.
Knowledge check two. Your SecOps quote lists one hundred and forty fulfilled users. The SOC has sixty analysts and twenty five remediators. The other fifty five are managers and reporting consumers. What is the count? A, one hundred and forty, everyone who needs access to the data. B, eighty five, the active analysts and remediators. C, sixty, incident responders only. D, one hundred and forty, but negotiate a volume discount. Pause here, and think about what the fulfilled user metric actually includes.
The answer is B, eighty five. The metric counts active analysts, remediators, and threat hunters, and it excludes view only reporting consumers, so those fifty five managers do not belong in it. Answer C undercounts by dropping the remediators, who are fulfilled users doing entirely real work on findings. And answer D is the expensive habit this whole course argues against, because at five figures per user, negotiating a discount on fifty five people who should never have been counted is worth a small fraction of simply removing them. Run that arithmetic once and it changes how you read a quote forever. Over counted fulfilled users added ten to twenty percent against a clean baseline in the estates we reviewed, and at these unit prices ten percent is a very large number.
Now IRM, the risk estate, four layers. The Now Platform base underneath, the fulfiller subscription the packs sit on, which you already own, so the risk conversation is incremental to it rather than separate from it. The IRM packs themselves, policy and compliance, risk, audit, vendor risk and their siblings, each on its own product metric and each needing to be scoped to the population that actually works risk. The legacy GRC terms, prior era module definitions and metrics sitting in older contracts, which get mapped explicitly at renewal, or the account team maps them for you. And the bundled extras, capabilities packaged into risk bundles that the programme never deployed, measured against usage, with ten to twenty percent recoverable at renewal for buyers who bring the measurement. The note is the one to hold on to. IRM is the current family, GRC is the prior name, and older contracts carry GRC era terms that need explicit mapping to current packaging. That mapping conversation is a repricing conversation whichever side of the table opens it.
Guest analyst clip. Risk licensing goes wrong in a way that is almost sympathetic, because it goes wrong for a good reason. Risk is genuinely an enterprise wide concern. Every executive will tell you that risk is everybody's business, and they are right, and that is exactly how the licence ends up scoped to everybody. I reviewed a programme where the risk modules were entitled across several thousand people on the reasoning that risk ownership sits with the business, not with the risk team. Sound governance thinking. Then we pulled the usage data. The number of people who had opened a risk module in the previous quarter was in the low hundreds, and it was the risk and compliance function plus a handful of control owners. Everybody else received their risk information the way most people do, in a report, in a meeting, in an email from somebody who did open the module. So the organisation was paying for enterprise wide access to deliver an experience that was, in practice, enterprise wide reporting. And the fix is not to argue that risk does not matter to the business. The fix is to notice that the licence pays for people who open the module, and the report reaches everybody else for free. Scope the entitlement to the working population, keep the reporting universal, and you have changed nothing about your governance and quite a lot about your bill.
Scope the entitlement to the working population and keep the reporting universal. Notice that this one is not a data quality problem or a drift problem, it is a definition problem, because somebody licensed a concept instead of a team. Let's name that error properly, because it has a shape you will recognise elsewhere.
Five points on the scoping error. The error itself, entitlement scoped to the whole organisation when the working population is a risk and compliance team measured in dozens. The evidence, twenty five to forty percent of licensed risk module access sitting with people who never opened the module across our reviews, and that is people who never opened it, not people who opened it rarely. Why it happens, which is the sympathetic part, because risk feels enterprise wide as a concept so the licence gets scoped to the concept rather than to the people doing the work. The compounding factor, which is that risk modules meter on their own definitions rather than on the platform's, so a programme scoped on a platform assumption is wrong twice over, once about the population and once about the unit. And the fix, which is unglamorous. Measure who opens the module, scope to them, and do that measurement before the renewal meeting rather than during it, because a number you bring is evidence and a number you discover in the room is an admission.
Knowledge check three. Your contract still uses GRC era module names and metrics. Your renewal is in six months. Who should perform the mapping to current IRM packaging? A, ServiceNow, they know the current packaging best. B, you, before the renewal, because the mapping is a repricing. C, nobody, legacy terms carry forward automatically. D, jointly, in the renewal meeting itself. Pause here. You have met this exact pattern before, in session seven.
The answer is B, you, before the renewal. The mapping conversation is a repricing conversation whichever side opens it, which is the tier migration lesson from session seven applied to an entirely different product family. Answer A hands the pen to your counterparty on a document that sets your price, and they will map it accurately and in their own interest, which are not contradictory things. Answer C assumes retired definitions survive a renewal, and they do not, because that is essentially what a renewal is for. And answer D sounds collaborative and means arriving without a position, which in practice is the same thing as accepting theirs. Do the mapping yourself, write down what each legacy term becomes and what it should cost, and walk in with that document. Six months is plenty of time. Six weeks is not.
Module four closes here, five sessions and six product families whose units share almost nothing. But four things did repeat, and those are what you carry forward. Every product has its own unit, fulfillers, employees, devices, managed configuration items, fulfilled users, publishers, so the first question on any line is always what is being counted. The count drifts upward by default, because roles, records, connectors, and scopes all accumulate without anybody deciding they should, in every single family we covered. Evidence resets the count, because activity data, deployment maps, and usage records moved every one of these lines, usually by double digits. And attachment timing matters, because modules negotiate better inside a platform renewal than standalone mid term, in every family, for the same structural reason. Four sentences that survive across six products with nothing else in common. That is the useful part of module four.
Guest analyst clip. I want to say something about the specialist estate as a whole, because there is a pattern that runs across SecOps and risk and it is not really about licensing. These products get bought by people who are under pressure. A security director buying incident response tooling has usually just been through something, or has just read about somebody else going through something. A risk officer buying compliance tooling has usually got a regulator or a board asking questions. And that pressure is completely legitimate, and it is also the single best selling condition in enterprise software, and everybody involved knows it. What I have seen work is very simple and it does not slow anything down. Somebody who is not under that pressure reads the quote. Not to block it, not to second guess whether the capability is needed, just to ask the four questions we have been asking all module. What is the unit. How many are we really counting. What is in the bundle that we are not going to deploy. And what does this look like attached to the renewal instead. Those four questions take an hour and they do not delay a security programme by a single day. The organisations that lose money here are not the ones that bought quickly. They are the ones where nobody outside the pressure ever read the paper.
Somebody who is not under the pressure reads the quote. That is the whole control, and it takes an hour. Module five turns to the platform layer itself, App Engine and the build versus buy decision, Integration Hub and transaction metrics, the assist pool governed properly, and the instances underneath all of it.
Three sentences. Connectors carry an edition allowance and twenty to forty thousand dollars a year above it, with bidirectional integrations sometimes counting twice, and they arrive during proofs of concept without the contract ever updating to match. SecOps modules license independently on fulfilled users at five figures each, so the bundle discount only pays when all three genuinely deploy, and the metric excludes view only reporting consumers. And IRM packs meter on their own units rather than the platform's, GRC era contract terms need a mapping that is really a repricing, and twenty five to forty percent of licensed risk access sat with people who never opened the module.
Homework, about an hour, and the first item is the highest value piece of homework in this entire module. Inventory the connectors, every deployed SecOps integration, whether each one is bidirectional, and your edition's allowance. That is the six figure item. Split the fulfilled users, active analysts and remediators against managers and reporting consumers, and price the difference at five figures each so the number lands properly. Test the bundle, which means for each SecOps module you hold, name the team, the workflow, and the go live date, and treat the blanks as candidates to drop. Read the risk contract and work out whether it uses GRC era or IRM era language, because if it is GRC then that mapping is yours to do before somebody does it for you. And count the risk module openers, how many licensed people actually opened a risk module last quarter. Expect that answer to be uncomfortable.
Five guides. The SecOps licensing guide has today's connector economics, the module metrics, the list prices, and the bundle arithmetic in written form, which is worth having when you are checking your own allowance. SecOps licensing for security operations gives the security team's view of the same estate, with the fulfilled user definition and the quarterly review discipline, and it is the one to forward to your SOC lead. The GRC and IRM licensing guide covers the risk packs, their own metrics, the GRC to IRM mapping, and the scoping error that puts twenty five to forty percent of access with non users. The license rightsizing playbook has the measurement discipline that produces the evidence every one of these modules responds to. And the ServiceNow products list for 2026 puts the specialist estate in context against everything else module four covered. That is module four complete. Next time we open module five with App Engine and the build versus buy line, where an architecture decision quietly becomes a multi year licensing commitment. See you there.