How the Pillars Work — Baselines & Industry Profiles
The Pillars of Technology are the general practices DTC follows and the baselines we can commit to for ourselves and every client. They are deliberately vendor-neutral: products change, the practice and the commitment should not. Where a product is named, it is an example of what we use today, not the standard itself.
How every pillar page is written
| Layer | What it says | Example |
|---|---|---|
| Practice | What we do and why — the principle that survives a vendor change. | Every endpoint runs a managed EDR watched by a 24/7 SOC. |
| Baseline | What we commit to for every client in scope — specific enough to check. | Agent installed and reporting on 100% of managed Windows endpoints and servers; an unhealthy agent alerts. |
| Today we use | The current product(s), named as examples. | Blackpoint Cyber. |
How a baseline is implemented in a specific product — settings, scripts, click paths — belongs in that product's operations book (Network Operations, Endpoint Operations, Backup Operations, Servers), which links back to the pillar. If an operations page or a script disagrees with a pillar, one of them is wrong; raise it.
Industry profiles
The baseline is the same for every client. What changes by industry is how fast we move, which platforms we can use, and what extra evidence we keep. Most clients are on the General profile; dental and healthcare practices are General plus HIPAA; government contractors handling CUI are the exception that moves fastest.
| Area | General business | Dental & healthcare | Government contractors (CMMC / CUI) |
|---|---|---|---|
| Compliance driver | Contract and cyber-insurance requirements | HIPAA Security Rule | CMMC Level 2 / NIST SP 800-171, DFARS |
| Windows patch approval | Deliberately behind release. Patches are rejected on release and approved once they have aged without incident: critical security immediately; high-priority security after 7 days (never later than 14); medium security and enhancements after 30 days; anything still unapproved auto-approves at 60 days (security) or 180 days (enhancements). Five incident tickets traced to one patch pulls it. The point is stability for line-of-business software over being first. Procedure: MSA Windows OS Patching. | As soon as released. Updates are not held for ageing. Never slower than the CUI timelines: zero-day under active exploitation 72 hours; critical and CISA KEV 15 days; high 45 days; medium 90 days. Source: Patch Management Policy (POL-SI-002). | |
| Line-of-business software | Vendor-supported versions | Practice-management and imaging vendors certify OS and SQL versions late, which is why patches and feature updates are held; vendor compatibility is checked before any OS or SQL upgrade. | Must also be in scope of the client's System Security Plan |
| Microsoft 365 tenant | Commercial | Commercial | GCC High where CUI requires it |
| Automation and tooling | Full DTC automation stack (e.g. NinjaOne, ninja-one-automation scripts, CIPP) | GCC High rules out CIPP and most of the automation stack; recurring work is engineer time. Every tool must be approved for the CUI boundary. | |
| Device management | RMM-managed (today: NinjaOne); Intune for mobile devices and compliance | Intune as the control point inside GCC High; RMM only where approved for the boundary | |
| Logging & review | Firewall and security logs to a SIEM where the client has one (e.g. Blumira); otherwise retained on the device | SIEM required, with recurring log, vulnerability and patch reviews as part of the service | |
| Change evidence | Every change on a HaloPSA ticket | Same, plus records kept as assessment evidence (patch logs, exception register, POA&M) | |
Client-specific exceptions
Any client may differ from its profile for a documented reason — performance, the client's own choice, a vendor constraint, a contract term. The exception and its reason go in that client's documentation; a client with nothing recorded is on its profile's defaults. This applies to every baseline in the book (RPO/RTO and retention included).
Relationship to the MSA Security Baseline
The DTC MSA Security Baseline (March 2025) is the client-facing statement of baseline protections referenced from the MSA. It predates several pillars and still names retired tools (Blackpoint SNAP agent, ZeroTier). Where it and a pillar disagree, the pillar is current; the MSA baseline needs reconciling against these pages before it is next sent to a client.
Open
- Other industries we serve (beyond general, dental/healthcare and government contractors) and how they differ — to be added as they are defined.
- Whether General and Dental differ anywhere beyond HIPAA framing — currently treated as the same operational profile.