Secure Cloudflare + DigitalOcean Law Firm Subdomains: FTC & State Privacy Checklist

Secure Cloudflare + DigitalOcean Subdomains for Law-Firm Client Portals and AI Tools (FTC-Style + State Privacy/AI Checklist)

This guide is for law-firm partners and administrators, plus IT/ops and product owners shipping client portals and AI pilots on subdomains (for example, portal.yourfirm.com or ai.yourfirm.com). The goal is practical: a configuration and governance checklist you can apply in Cloudflare and DigitalOcean that aligns with FTC-style expectations for “reasonable security” (access control, encryption, monitoring, and vendor oversight) and the growing patchwork of state privacy/AI requirements. The core risk is simple: teams often treat subdomains as “side projects,” so they bypass the hardening on the main website and become the easiest breach path (credential theft, file exposure, DNS takeovers, or shadow analytics). If you need a quick primer on the mechanics of subdomains in this stack, see Subdomains for Law Firms: Building Client Portals, AI Tools, and Internal Systems.

Scope note: this is implementation guidance, not legal advice; obligations vary by state, data type (PII/PHI/financial), and client contracts.

Fast compliance mapping: technical controls → legal expectations

Use the sections below as your table-of-contents: they mirror what regulators and clients usually mean by “reasonable security” (even when the rule text is vague). In practice, this also prevents the common failure mode where a new portal or AI subdomain ships without the controls already applied to www.

• Access control & MFA → least privilege, account lifecycle, and strong authentication (especially for Cloudflare/DigitalOcean admins and portal admins). Pair technical enforcement with user training (see Train your law firm employees in security principles).
• Secure transmission (Origin TLS + end-to-end HTTPS) → “protect data in transit” and reduce credential/session theft risk.
• Vendor oversight (DPAs, subprocessors, SOC2/ISO where appropriate) → processor contract requirements, audit rights, and AI data-use limits (see FTC Report on Cloud Providers and AI Partnerships).
• Logging + monitoring → detection, investigation, and defensible “we would have noticed” capability.
• Data retention + deletion → minimize breach impact and control AI training/data reuse exposure.
• Incident response + notification readiness → state timeline variation plus contractual notice obligations (see What are the consequences of a breach for your firm?).

Quick “minimum viable hardening” checklist

• Require MFA for Cloudflare, DigitalOcean, code repo, and portal/admin users.
• Set Cloudflare SSL/TLS to Full (Strict) (no “Flexible”).
• Deploy a WAF/rate-limits for portal/AI subdomains (login, upload, API routes).
• Lock down origin access (DigitalOcean firewall; restrict SSH by IP/VPN).
• Centralize Cloudflare + app + DO activity logs off the Droplet.
• Define log retention and application data retention (with deletion owners).
• Inventory vendors/subprocessors per subdomain; execute/confirm DPAs.
• Write an IR runbook for DNS takeover + credential compromise.
• Test backups/restores (Droplet snapshots, DB, object storage) on a schedule.
• Run quarterly access reviews and remove shared/admin accounts.

Step 1: Design the subdomain architecture to isolate risk (before you touch Cloudflare)

Before DNS and certificates, decide how you’ll segment trust. A clean subdomain map limits blast radius when (not if) a pilot tool ships with weaker controls.

• Recommended patterns: keep user populations and privileges separate: portal.example.com (clients), ai.example.com (AI UI), api.portal.example.com (API), and admin.portal.example.com (staff-only) with tighter access (VPN/IP allowlists, shorter sessions, mandatory MFA).
• Environment separation: use distinct staging/dev hostnames (for example, staging-portal.example.com) and, where feasible, separate databases/buckets and API keys. Don’t point staging at production data “temporarily.”
• Example scenario: the firm launches ai.example.com for a pilot and reuses portal admin credentials. Later they learn the pilot bypassed the main site’s security plugin. Fix by isolating identity (separate admin roles), isolating data stores, and putting the AI subdomain behind the same Cloudflare protections as the portal.
• Verification + documentation: maintain an asset inventory: each subdomain’s owner, purpose, data types, vendors/subprocessors, and retention targets (this becomes your incident-response asset map). For more on choosing portal/AI subdomains, see Subdomains for Law Firms: Building Client Portals, AI Tools, and Internal Systems.

Step 2: Configure Cloudflare DNS correctly (and decide proxy vs DNS-only intentionally)

In Cloudflare, treat DNS as a security control — not just a routing step. For DigitalOcean Droplets, you’ll typically create an A record (and AAAA if you’ve enabled IPv6) pointing the subdomain to the Droplet IP; use CNAME only when you’re intentionally aliasing to another hostname-managed service. Document each record’s purpose so you can audit “shadow” subdomains later.

Proxy choice matters: for client portals and most AI tool UIs, use Proxied (orange cloud) to put Cloudflare in front of the origin — enabling WAF/bot controls, rate limits, and hiding the origin IP. Use DNS-only (gray cloud) only when you must (some verification flows or non-HTTP services); you’re giving up edge protections and directly exposing the origin.

Subdomain-specific boundaries: where feasible, isolate portal/AI hostnames with their own rulesets (at minimum, distinct WAF/rate-limit rules and separate access/admin ownership).

Example failure: a mis-pointed CNAME (or wrong Droplet IP) routes portal traffic to staging. Check Cloudflare DNS target, DigitalOcean Droplet IPs, and whether the hostname resolves to Cloudflare anycast IPs (proxied) versus the origin (DNS-only).

For a walkthrough of the mechanics, see How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers and Subdomains for Law Firms: Building Client Portals, AI Tools, and Internal Systems.

Step 3: Force end-to-end TLS (Origin TLS) so credentials and client files never travel in plaintext

For portals and AI tools that handle client data, “Flexible” SSL is usually unacceptable: it encrypts only between the visitor and Cloudflare, while Cloudflare-to-origin can be plaintext HTTP. Set Cloudflare’s SSL/TLS mode to Full (Strict) so the origin must present a valid certificate — this prevents silent downgrade paths that enable credential and session theft.

• Origin CA certs: generate a Cloudflare Origin Certificate in the dashboard, install it on your Droplet (or reverse proxy like Nginx/Caddy), and calendar a renewal/rotation process. Keep the private key restricted and treat it like any other secret.
• TLS minimums: enforce TLS 1.2+ (TLS 1.3 where supported) and avoid legacy protocol support unless you have a documented exception.
• HSTS + cookies: enable HSTS on the portal subdomain and set cookies to Secure + HttpOnly with an appropriate SameSite policy (especially if you embed across subdomains).
• DigitalOcean hardening: patch on a defined cadence; disable weak protocols; configure the DO firewall to allow only 443 (and 80 only if you need HTTP→HTTPS redirects) plus SSH from restricted IPs/VPN.

Example scenario: a portal ran “Full” (not strict) with an expired self-signed origin cert; during an outage, engineers flipped to “Flexible” to restore access. Avoid this by using Origin CA with Full (Strict), monitoring cert expiry, and documenting an emergency playbook that never involves downgrading transport security.

Step 4: Implement MFA and access control that matches real law-firm workflows (clients, staff, vendors)

Law-firm portals fail when “admin convenience” overrides access discipline. Start by defining roles (client, attorney, staff, vendor/support, admin) and then make MFA and permissions role-based, not optional.

• Mandatory MFA: require MFA for Cloudflare and DigitalOcean administrators, source code repos, password managers, portal admins, and any support tooling that can reset passwords or access client files.
• Client MFA + step-up auth: offer client MFA by default, and require step-up authentication for high-risk actions (bulk download/export, payment changes, changing contact info, adding users).
• MFA choices: prefer authenticator apps or hardware keys; avoid SMS where feasible. Define a recovery-code policy (storage, rotation, and who can use them) so “account recovery” doesn’t become your weakest link.
• Least privilege: eliminate shared accounts; use joiner/mover/leaver workflows with immediate offboarding and quarterly access reviews.
• Session basics: shorter sessions for admins, re-auth for sensitive actions, and tighter limits on admin endpoints (especially on admin.portal).

Example: a paralegal account reused across matters is phished; the attacker exports every client file. Mandatory MFA, matter-scoped roles, and step-up auth for exports would have reduced the blast radius and improved investigation. Reinforce the policy with training: Train your law firm employees in security principles.

Step 5: Build vendor governance into the deployment (DPAs, AI provider terms, subprocessors, and assessments)

Portals and AI tools often rely on Cloudflare, DigitalOcean, and multiple “small” vendors (analytics, email/SMS, chat widgets). Treat each one as part of your security perimeter.

• Paper the minimum: a DPA/data processing terms for each vendor handling client data; a subprocessor list plus a change-notice mechanism; data-use limits (no training/service-improvement on firm/client data unless expressly approved); breach notice timing/cooperation; and deletion/return at termination. Cloudflare, for example, publishes a customer DPA and maintains a subprocessor list referenced in it.
• Assessments (simple decision tree): ask for SOC 2 Type II or ISO 27001 where the vendor hosts or can access sensitive portal/AI data; require a penetration test when you expose internet-facing auth, file uploads, or AI prompt-ingestion paths; use a lightweight security questionnaire for low-risk vendors (and document the rationale).

Example: the firm enables a chatbot over client documents, but the vendor’s terms allow broad “service improvement.” Mitigate by tightening contract language (no training, scoped retention, prompt deletion) and limiting what you send (redaction, least-privilege tokens, separate environments). See Creating a chatbot for your firm that uses your own docs and FTC Report on Cloud Providers and AI Partnerships.

Step 6: Set logging, monitoring, and retention so you can actually investigate an incident (and minimize what you store)

“Reasonable security” isn’t just prevention — you need evidence to scope an incident. Start with a minimum logging set, centralize it, and then retain only what you can justify.

• What to log (minimum): authentication events (logins, failures, MFA, resets, session creation); admin actions (role changes, exports/downloads, config changes); network/app signals (WAF events, rate limits, API requests, file/object access); and cloud control-plane activity (Cloudflare audit logs and DigitalOcean activity logs).
• Where to store logs: ship logs off the Droplet to a separate project/bucket/account with tight IAM (append/write-only where possible, restricted read access) and basic integrity controls so attackers can’t erase evidence.
• Retention policy: keep high-volume edge/WAF logs shorter (weeks) and keep audit/security logs longer (months) based on investigation needs and contractual expectations. Use a simple retention table with columns for log type, retention, reason, and owner.
• Monitoring + alerting: alert on unusual admin actions, geo anomalies, spikes in 401/403s, repeated failed logins, and large export/download events.

Example: after suspicious access, the firm can’t determine scope because logs rolled off in 7 days. Fix by lengthening audit-log retention, centralizing logs outside the app server, and ensuring alerts trigger early enough to preserve evidence without “keeping everything forever.”

Step 7: Incident response readiness (obligations, timelines, and a runbook you can execute)

For subdomains, incident response is often a DNS and identity problem first. Pre-stage the basics: an asset inventory (subdomains, owners, data types), vendor contacts (Cloudflare/DigitalOcean/AI providers), breach counsel, and your cyber insurer’s notice requirements. Also schedule and test restores (Droplet snapshots, database backups, object storage versioning) so “recover” is real.

Use a lightweight runbook you can execute: Detect → Triage → Contain → Preserve evidence → Eradicate → Recover → Improve. Key decision points: what data types were exposed, which clients/states are implicated, and what contract notice terms apply (often stricter than statutes). Notification timing varies by state, but many laws key off acting without unreasonable delay.

Example (first hour): if Cloudflare credentials are compromised and DNS is changed to redirect portal traffic, immediately rotate Cloudflare credentials (password, revoke sessions, roll API tokens) and revert DNS changes. Cloudflare explicitly recommends reviewing Audit Logs during compromise response and storing them externally (Logpush) to avoid losing evidence.

Document root cause, remediation, and control updates (this is what “reasonable security” looks like in hindsight). See What are the consequences of a breach for your firm? and Navigating the patchwork: state-by-state AI laws in the United States.

Actionable Next Steps (use this as your implementation checklist)

• Turn on MFA for Cloudflare and DigitalOcean (and your code repo/password manager) and eliminate shared admin accounts.
• Set Cloudflare SSL/TLS to Full (Strict), deploy Origin CA certs, and add a calendar reminder for renewal/rotation.
• Put portal/AI subdomains behind Cloudflare (proxied) and add WAF + rate limits for login, uploads, and API routes.
• Lock down the origin: DigitalOcean firewall to 443 (and 80 only if required), restrict SSH to VPN/allowlisted IPs, and patch on a defined cadence.
• Centralize Cloudflare/DO/app logs off-server, restrict access, and publish a logging + retention table with owners and durations.
• Review/execute DPAs and confirm AI vendor data-use limits (no training/service-improvement on client data by default).
• Run a tabletop exercise for DNS takeover + credential compromise and validate backup/restore procedures end-to-end.

If you want a combined technical hardening review plus vendor/AI contract cleanup, contact Promise Legal (see promise.legal).

Optional add-ons for SEO conversion

• FAQ targets: “Should our portal be proxied in Cloudflare?”, “Is Cloudflare Flexible SSL acceptable for client portals?”, “Do clients need MFA?”, “How long should we retain audit logs?”, “Can our AI vendor train on our data?”, “What happens if DNS is hijacked?”
• Downloadable checklist: offer a one-page PDF and track scroll depth + CTA clicks to see where readers convert.