How DLPST sizes and scores
The same method is applied to every OEM. Every step appears on the result page and in the Word, PowerPoint and Excel exports.
1. Sources
All vendor facts - products, capability ratings, server requirements, capacities, ports, best practices and rollout phases - come from the OEM's own public websites and documentation portals (for example techdocs.broadcom.com, help.forcepoint.com, docs.netskope.com, proofpoint.com and fortra.com / digitalguardian.com). Each fact carries the URL it was taken from and is linked wherever it is shown. Anything that could not be confirmed on an official page is listed under Not verified in the OEM knowledge base and is never used as a fact. Where an OEM does not publish a figure that sizing needs, DLPST says so and uses a clearly labelled planning assumption instead.
2. Workload
The environment you describe is turned into end-of-term figures, shared by every vendor:
| Growth | Every count is multiplied by (1 + growth)^term. |
|---|---|
| Endpoint agents | Windows + macOS + Linux endpoints + VDI sessions. |
| Mail busy hour | Users x messages per user per day x 15% (planning assumption for the share of a day's mail in its busiest hour). |
| Web | Peak egress Mbps entered, grown. |
| Scan rate | (File share + SharePoint TB) / (days for a full pass x scanning hours per day). |
| DSPM | Cloud accounts (AWS + Azure + GCP), data stores, and TB under management (IaaS/PaaS + SaaS). |
| Incidents | As entered, or 0.05 per user per day for a tuned policy set (planning assumption). |
| Incident storage | Incidents/day x retention days x 250 KB (planning assumption) - used where the OEM hosts the incident database on-premises. |
3. Requirements
The environment decides many requirements on its own: macOS endpoints make a macOS agent a must have, Microsoft 365 mail makes cloud email DLP one, AWS accounts in scope make AWS DSPM one, an on-premises deployment preference makes an on-premises console one, and so on. The remaining capabilities (EDM, fingerprinting, OCR, ML, risk-adaptive protection, labelling, SIEM, API ...) take the priority you set.
4. Fit score
Each OEM's documented rating for each required capability is converted to a score and weighted by priority:
| OEM rating | Score |
|---|---|
| Native | 1 |
| Add-on product | 0.85 |
| Partial | 0.5 |
| Not documented | 0.25 |
| Not available | 0 |
| Your priority | Weight |
|---|---|
| Not needed | 0 |
| Nice to have | 1 |
| Should have | 3 |
| Must have | 5 |
fit % = sum(weight x score) / sum(weight) x 100
Ranking puts the OEM with the fewest must-have gaps first (a must-have the vendor does not offer at all), then the highest fit. A vendor that is excellent on average but cannot do one thing you must have should not win on its average. "Add-on product" means the OEM offers it as a separate product or licence - it counts as meeting a must-have, at a small discount, because it adds cost and integration work. "Not documented" is scored low rather than zero: it means the public documentation reviewed did not show it, not that it is impossible - verify with the OEM.
Fit is also shown per capability area (endpoint, channels, cloud, data at rest, DSPM, detection, protection, operations, deployment).
5. Architecture sizing
Each OEM is sized with its own published rules - for example the maximum agents per endpoint/detection server, the tiered hardware requirements for management and database servers, and the throughput guidance for network, email and discovery components. Where a component is vendor-hosted SaaS, DLPST lists it with no hardware and sizes only the customer-side pieces (connectors, gateways, on-premises scanners, forwarders). Server counts include an N+1 spare when high availability is selected and a standby set when a DR site is selected. Detection servers are sized to run at no more than 75% of the published capacity at the end of the term.
6. Diagrams
The logical diagram shows the channels in scope, the component that inspects each one, the policy/incident plane and the integrations. The implementation diagram places every component, with quantity and specification, into its network zone - endpoints, perimeter/DMZ, customer data centre, OEM cloud, customer cloud and SaaS - with the connections and ports the OEM documents.
7. What this is not
DLPST is a pre-sales sizing and selection aid. It does not produce prices, and published capabilities change with every release. Confirm the final bill of materials, licences and hardware with the OEM or its partner before quoting.