Do-Not-Contact Enforcement: An SLA-Bound Runbook

Recommendation: Treat do-not-contact as a production incident class with an SLA, not a preference field. Scenario: A candidate emails recruiting@ with a privacy request: "Do not contact me." A coordinator updates a field in the ATS. Two days later, a sourcer pulls the same profile from a talent pool and sends an outreach sequence from a separate tool. The candidate forwards both emails to Legal, asking why the company ignored the request. Operational risk shows up immediately: - Audit liability: You cannot produce a single timeline proving suppression across every outbound system. If it is not logged, it is not defensible. - SLA breach: recruiting pauses outbound campaigns while ops verifies which tools still have the candidate in active sequences. Time-to-offer delays cluster at moments where policy is uncertain. - Cost exposure: you waste cycle-time on candidates you are not allowed to contact, and you increase the chance of escalations that pull leadership into reviews instead of closing roles. - Fraud risk: ad hoc deletion in one tool can erase integrity signals while the same person re-enters via another email. You need DNC controls without turning your stack into a fraud blind spot.

Recommendation: Stop expecting your ATS, assessment tools, and messaging platforms to coordinate policy enforcement without an event model and reconciliation. Legacy tooling patterns create DNC breaches because they assume a single system update is enough. In reality, outbound contact happens in diverse systems: recruiter inboxes, SMS providers, marketing automation, scheduling, assessment invites, and even hiring manager forwards. Why the market did not solve it: vendors optimize for their own workflow step, not for cross-system policy consistency. That produces sequential checks instead of parallelized checks, no standardized rubric storage for exceptions, and no ATS-anchored audit trails that Legal can rely on. When recruiters work around delays, they create shadow workflows, which become integrity liabilities.

Recommendation: Assign one owner for policy, one owner for enforcement plumbing, and one owner for exception decisions. Anything else becomes "everyone and no one." Ownership model: - Recruiting Ops owns: the DNC workflow definition, field hygiene, SLA dashboards, and downstream system coverage. - Security owns: access control to change DNC state, audit policy, retention rules, and evidence pack requirements. - Hiring Managers own: exception justification when a candidate is re-engaged (if allowed), and rubric discipline for any related decision-making. Automation vs manual review: - Automated: propagation to all connected tools, outbound send-time checks, block-attempt logging, reconciliation jobs. - Manual review: exceptions (for example, candidate reconsent), disputes, and any policy overrides. Manual review without evidence creates audit liabilities. Sources of truth: - Policy source of truth: ATS record for DNC status and reason code, with immutable timestamps. - Enforcement points: every system that can send outreach must check DNC at send-time, not only at import-time. - Evidence store: ATS-anchored audit trail plus evidence pack attachments (request, approvals, propagation log excerpts).

Recommendation: Implement DNC as an instrumented workflow: identity gate before access, event-based triggers, automated evidence capture, and dashboards. Operating model checkpoints:

Recommendation: Use IntegrityLens as the ATS-anchored control plane that logs DNC decisions, gates identity before sensitive steps, and produces evidence packs when Legal asks for proof. Where it fits operationally: - Enforces identity gating before access to high-risk steps, so DNC state and overrides are attributable to a verified operator. - Maintains ATS-anchored audit trails with immutable, timestamped event logs for DNC state changes and enforcement actions. - Produces immutable evidence packs that bundle the request, reason codes, approvals, and propagation logs for review. - Supports step-up verification patterns that reduce fraud exposure when a previously suppressed identity reappears in the funnel. - Uses zero-retention biometrics architecture for verification steps, reducing the need to store sensitive biometric artifacts while still logging the verification outcome.

Do not do these three things: - Treat DNC as deletion-only. You erase linkage signals that help detect repeat attempts, but you still fail to block outreach from other tools. - Enforce DNC only at import-time. Candidates can enter sequences later through lists, referrals, or manual adds. Enforcement must happen at send-time. - Allow ad hoc overrides in Slack or email. Exceptions must be policy-validated, time-bounded, and logged with reviewer accountability.