Your MSP contract promises full traffic inspection at a fixed latency — how do you state the real ceiling before an intruder finds it?

## Why the clause is unbuyable as written A service description that promises full traffic inspection and quotes a latency figure at a contracted throughput has committed to three numbers that trade against each other. Deep inspection costs buffer memory per flow and cycles per packet; refusing to truncate raises latency and lowers the concurrent-flow ceiling; holding the latency figure at peak requires truncation and flow offload to be enabled. The rated throughput on which the platform was sized was itself measured with those savings switched on. So the contract does not describe a configuration that exists. That is not a scandal — it is the normal result of a technical ceiling being translated by people who were not shown it — but it becomes one during an incident, when a tenant learns the ceiling for the first time from an attacker. ## Turning a configuration into a sentence The work is translation, and it must survive being read by a lawyer and a tenant's risk owner: - "Content inspection of file transfers covers the first N megabytes of each transfer in each direction." - "Connections are inspected until an allow decision is reached; subsequent traffic within that connection is forwarded without content inspection." - "Protocol body inspection covers the first M kilobytes, which is a smaller limit than the transfer figure above." - "Above sustained load of X, inspection is reduced in this published order, and reduction periods are recorded and reported." Four plain sentences replace one unbuyable one. Each is verifiable, and each is a number an engineer can defend. Notice that no sentence promises detection of anything — the ceiling describes what is *examined*, and examination is a precondition for detection, not a substitute for it. ## Make it measurable, then report it A ceiling stated once is a claim. A ceiling reported monthly is a control. The instrumentation already exists on the platform: streams truncated at the depth limit, bytes forwarded on the fast path, bytes passed during bypass or degraded mode, and time spent in degraded mode. Those four numbers turn the service description into a measurement, and they are also the evidence you will need in two situations that both eventually arrive: the capacity request, and the post-incident review. A tenant told "we inspect the first N megabytes" and shown "and last month 3% of transfers exceeded it" is a tenant who can make a decision. ## The priced choice, and who signs Once stated, the ceiling becomes a business decision with three honest outcomes: 1. **Fund headroom.** More inspection capacity, deeper limits on high-value classes, or dedicated aggregation for this tenant. Costs money and someone must approve it. 2. **Narrow the scope.** Inspect less traffic more thoroughly — full depth on egress paths carrying regulated data, a short prefix elsewhere. Costs nothing but requires agreeing what matters. 3. **Accept the ceiling.** Written, dated, and signed by the tenant's risk owner. The organisational failure to avoid is letting the tenant's network engineer sign. That person understands the box and will nod; they usually cannot fund an alternative and are not accountable for the residual risk. The signature has to come from whoever can say no and mean it — and if nobody on the tenant side will sign, that refusal is itself the answer: the promise gets renegotiated or withdrawn, never quietly kept. ## The shared-tenancy disclosure On a shared inspection platform the ceiling is not per-tenant even though the contract is. Concurrent flows, buffer and cycles are consumed by whoever is busiest, so one tenant's replication window sets the depth every other tenant receives that hour. This must be disclosed, because it is the clause a tenant would most reasonably object to and the one they cannot discover for themselves. It also produces the cleanest upsell in the estate: dedicated aggregation, or a reserved share, priced. Disclosure converts an invisible cross-tenant dependency into a product decision. ## What you do not do Do not quietly raise limits to match the words — that trades an honest ceiling for an unfunded latency breach and a different broken clause. Do not let sales requote the datasheet. Do not accept "we will fix it if it ever matters", because the moment it matters is the moment you are least able to. And do not describe the ceiling only in an internal runbook: an internal document protects the engineer, while the tenant's exposure is unchanged. The principle underneath all of it is that a security control's limits are part of the product. Stating them costs an awkward conversation once. Not stating them means the first person to describe them accurately to your tenant is the person who exploited them.