KRIs for your public digital footprint

Your public-facing marketing infrastructure is wide and busy: websites, subdomains, CDNs, third-party scripts, lead forms, campaign microsites, and email sending domains. It sits between the security team and the marketing team, and neither side owns all of it. Pages launch without a security review. Tags get added to a tag manager in an afternoon. A campaign microsite goes up on a subdomain and is never decommissioned. An email vendor starts sending on your behalf and nobody adds the domain to the DMARC inventory.

That gap is where the real attacks land. Magecart skimmers ride in on third-party JavaScript. Subdomains with dangling CNAMEs get taken over and serve attacker content under your name. Phishing campaigns spoof a sending domain that never moved past p=none. None of this is exotic, and most of it is invisible until a customer or an auditor finds it first. The KRIs below turn that blind spot into a measured signal, and they pair naturally with the product security, application security, and enterprise security domains in the same series.

If you are standing up this measurement from scratch, start with how to build a KRI program, then use the KRI reference library to map these signals to CIS Controls and your green/amber/red weighting. Watching the trend over time, not just the snapshot, is covered in reading the signal on drifting KRIs.

Why marketing web presence creates distinctive risk

Most security programs are built around infrastructure the team owns and operates. Marketing web presence breaks that assumption. It includes infrastructure owned by marketing and run by agencies, third-party tools installed through tag managers with little security review, subdomains and microsites spun up for campaigns and then forgotten, email-sending infrastructure operated by ESP vendors on your behalf, and forms and integrations that touch PII and payment data while sitting outside the scope of your security controls.

The surface is wide and it changes often: new campaigns, new tools, new email vendors. It is managed by teams whose primary incentive is speed, not review. So these KRIs depend on close work between security and marketing, and on an explicit definition of what "security approval" means for a marketing asset before it ships.

KRI inventory

1. Email domain authentication coverage

What to measure. The percentage of owned and marketed email-sending domains, including subdomains used for campaigns, transactional email, and marketing automation, that have SPF, DKIM, and DMARC configured at an enforcement policy.

Why it matters. Business email compromise losses now run higher than ransomware losses year over year. Every sending domain without DMARC enforcement is an open door for an attacker to send phishing that appears to come from your brand. DMARC at p=none gives you visibility only. It does not stop spoofing.

• DNS records: automated SPF, DKIM, and DMARC policy lookup against a complete inventory of owned domains (dig TXT example.com)
• Domain registrar account: the full list of registered domains, including parked and subsidiary domains that get missed
• Email service providers (Mailchimp, Marketo, HubSpot, Salesforce Marketing Cloud): sending domains configured in each platform
• DMARC monitoring platforms (Dmarcian, Valimail) and email security gateways with email fraud reporting such as Proofpoint and Mimecast: aggregate enforcement status and spoofing attempt data
• Marketing automation platforms: sending domain configurations

How to calculate. (Sending domains with DMARC at p=reject or p=quarantine plus SPF and DKIM all configured) ÷ (total email-sending domains identified) × 100.

Status	Criteria
Green	100% at enforcement policy; DMARC reporting active on all domains
Amber	All domains configured but one or more at p=none; or recent campaign domains not yet added
Red	Any sending domain with no DMARC; or the primary brand domain at p=none

2. Subdomain inventory completeness and takeover risk

What to measure. The count of active subdomains against the approved, documented subdomain inventory, plus the number of subdomains flagged as takeover candidates (a CNAME pointing to a decommissioned or unclaimed third-party resource).

Why it matters. Subdomain takeover is low effort and high impact. When a subdomain CNAME points to a third-party service (a Heroku app, GitHub Pages, an S3 bucket, an Azure blob) that has been torn down, an attacker can claim that resource and serve content from your subdomain. The visitor sees your domain in the address bar. Marketing creates this risk constantly: campaign microsites, launch pages, and event registrations get stood up on subdomains and rarely get formally retired.

• DNS enumeration tools (amass, subfinder, dnsx): passive and active subdomain enumeration
• Attack surface management platforms (Censys, Shodan, Detectify): continuous subdomain monitoring
• DNS zone files, if managed internally (BIND, Route 53, Azure DNS): export every record
• Marketing team: the list of active campaign pages, microsites, and event sites
• Agency and contractor inventory: subdomains created and managed externally

How to calculate. Completeness is (subdomains in the approved inventory) ÷ (subdomains discovered by enumeration) × 100. Takeover risk is the count of subdomains whose CNAME points to an unclaimed or decommissioned target.

Status	Criteria
Green	>98% inventory completeness; zero takeover candidates
Amber	90–97% completeness; 1–3 takeover candidates under active remediation
Red	<90% completeness; any takeover candidate unresolved >72 hours

3. Third-party JavaScript tag risk score

What to measure. The number of third-party JavaScript tags loaded on marketing web properties, sorted by risk tier. That includes unreviewed tags, tags loaded from domains with weak security posture, and tags with access to form data or payment flows.

Why it matters. Magecart and formjacking work by injecting malicious code into third-party scripts that marketing tag managers load. Every analytics tag, chat widget, A/B test script, and marketing pixel is a supply chain risk. A tag manager carrying 50–100 unreviewed third-party tags is an attack surface most security teams have never assessed.

• Tag manager audit (Google Tag Manager, Adobe Launch, Tealium): export the full list of active tags with source domains and trigger conditions
• Browser-based scanning (Screaming Frog, a custom crawler): enumerate every third-party script source loaded on each page
• Attack surface management platform: tag monitoring for new tags or changed scripts
• Content Security Policy headers: review the allowed script-src sources; gaps point to unreviewed tags
• Web application firewall logs: third-party script load requests

How to calculate. Classify each tag into a tier, then track the counts. Tier 1 (high risk) is tags from domains with poor security ratings, tags with access to payment or PII fields, and unrecognized tags with no documented business owner. Tier 2 (medium risk) is recognized vendor tags not reviewed in the last 12 months, and tags with broad DOM access. Tier 3 (low risk) is recognized, reviewed, minimal-access tags from reputable vendors.

Status	Criteria
Green	Zero Tier 1 tags; every tag has a documented owner and last-review date; CSP implemented
Amber	1–3 Tier 1 tags under review; or more than 50% of Tier 2 tags unreviewed
Red	Any unrecognized tag on a page with payment or PII forms; or no tag inventory exists

4. Marketing form PII handling risk

What to measure. The percentage of marketing forms (contact forms, lead capture, event registrations, newsletter signups) that transmit PII over HTTPS, route to reviewed and approved destinations, and have documented data handling procedures.

Why it matters. Marketing forms are PII collection points. A form submitted over HTTP, routed through an unapproved third-party service, or feeding a marketing tool that was never assessed for data handling creates regulatory exposure (GDPR, CCPA, state privacy laws) and breach liability. Marketing teams add new forms regularly without a security or privacy review.

• Web crawler or Screaming Frog: enumerate every form across web properties and check TLS status
• Marketing automation platforms (HubSpot, Pardot, Marketo): form destinations and data routing
• Privacy review records: which forms have been reviewed for data handling compliance
• Consent management platform (OneTrust, Usercentrics): consent flows tied to form submissions

How to calculate. (Forms with HTTPS plus an approved destination plus documented data handling) ÷ (total active forms discovered) × 100.

Status	Criteria
Green	100% HTTPS; >95% with documented data handling; every new form through security and privacy review before launch
Amber	All forms on HTTPS but with data handling documentation gaps; or forms added without review in the last quarter
Red	Any form on HTTP; or any form collecting PII that routes to an unreviewed third-party destination

5. Website TLS and certificate health

What to measure. The percentage of public web properties with valid, current TLS certificates using current cipher suites; the number of certificates expiring in the next 30 days; and the number of properties using deprecated protocols (TLS 1.0/1.1, SSL).

Why it matters. An expired TLS certificate throws a browser warning that hurts brand trust and conversions, and it is a security signal in its own right. Certificate management discipline, or the lack of it, tells you how tightly the marketing web infrastructure is actually run. Deprecated cipher suites leave visitors open to interception.

• Certificate monitoring services (Cert Spotter, crt.sh, SSL Labs): automated status, expiry, and configuration checks
• Attack surface management platform: continuous certificate monitoring across all subdomains
• Certificate Transparency logs: surface certificates issued for your domains that your team did not issue, a marker of phishing infrastructure
• CDN management console (Cloudflare, Akamai, Fastly): certificate inventory and expiry dashboard

How to calculate. Valid rate is (properties with valid, current TLS) ÷ (total web properties) × 100. Track the count of certificates expiring in under 30 days, and the count of properties still on TLS 1.0/1.1 or SSL.

Status	Criteria
Green	100% valid TLS; zero expiring in <14 days; zero deprecated protocols; CT log monitoring active
Amber	Any certificate expiring in 14–30 days; or any deprecated protocol with documented remediation
Red	Any expired certificate; any deprecated protocol with no remediation plan; or rogue certificates found in CT logs

6. Brand impersonation and phishing domain monitoring

What to measure. The number of newly registered domains impersonating your brand (typosquats, look-alikes, brand-plus-keyword combinations) detected in the trailing 30 days, and the number of active phishing pages using your brand assets.

Why it matters. Attackers register brand-impersonating domains to target your customers, employees, and partners. Your marketing team likely has no visibility into this, and your security team may not either. Proactive monitoring turns it from a reactive crisis into an ongoing signal.

• Domain monitoring services (DomainTools, Bolster, BrandShield, PhishLabs): automated look-alike registration monitoring
• Certificate Transparency logs: newly issued certificates for brand-keyword domain combinations
• DMARC aggregate reports: unauthorized use of your domain in email campaigns
• Search engine monitoring: brand impersonation pages indexed in search results
• Threat intelligence platforms (Recorded Future, Intel 471): phishing kit and infrastructure monitoring

How to calculate. Track monthly new look-alike registrations as a trend, active phishing pages confirmed using brand assets as a point-in-time count, and takedown success as (phishing pages taken down) ÷ (phishing pages detected) × 100.

Status	Criteria
Green	Monitoring active; new look-alikes detected and reviewed within 48 hours; active phishing pages taken down within 24 hours
Amber	Monitoring active but response time >48 hours; or monitoring is periodic rather than continuous
Red	No brand monitoring program; or active phishing pages using brand assets unaddressed >72 hours

7. Content Security Policy (CSP) coverage

What to measure. The percentage of marketing web properties carrying a properly configured Content Security Policy header that restricts unauthorized script execution, inline scripts, and unauthorized resource loading.

Why it matters. CSP is the primary browser-enforced defense against cross-site scripting (XSS) and Magecart-style injection. A CSP in report-only mode gives you telemetry. A CSP in enforcement mode actually blocks the attack. Most marketing properties have neither.

• Security headers scanner (SecurityHeaders.com, Mozilla Observatory): automated CSP header check across properties
• CDN or web application firewall console: CSP header configuration status
• Browser-based scan (ZAP, Burp Suite passive scan): CSP presence and policy strength
• DevOps or deployment pipeline: CSP header injection at deploy time

How to calculate. (Properties with an enforcement-mode CSP) ÷ (total public properties) × 100, tracked alongside the count still in report-only mode or running an overly permissive policy.

Status	Criteria
Green	Enforcement-mode CSP on all public properties; CSP violation reporting active and reviewed
Amber	Report-only CSP (monitoring, not blocking); or CSP present but overly permissive (unsafe-inline, unsafe-eval)
Red	No CSP on properties handling form data or payment flows; or no CSP program at all

Deriving these KRIs by source type

From DNS and domain infrastructure

• Query every owned domain for SPF, DKIM, and DMARC records with dig TXT example.com or via a DMARC monitoring platform.
• Run amass or subfinder against each apex domain and compare the results to the approved DNS zone.
• Resolve every CNAME chain and check for dangling or decommissioned targets.
• Subscribe to crt.sh or Cert Spotter for certificate issuance alerts on your domains.

From tag managers (Google Tag Manager, Adobe Launch, Tealium)

• Export the tag configuration: in GTM, go to Admin then Export Container, and parse the JSON for tag types, trigger conditions, and third-party script URLs.
• Map each unique script domain to a security rating (BitSight, SecurityScorecard).
• Flag tags with input, form, or payment-field listeners as high risk and review those first.
• Review who holds publish rights on the tag container. That is a security question, not just a marketing one.

From attack surface management platforms (Censys, Shodan, Detectify)

• Configure continuous subdomain discovery for all apex domains and alert on new subdomains.
• Use technology fingerprinting to catch deprecated CMS versions, unpatched plugins, and exposed admin interfaces on marketing properties.
• Pull a complete certificate inventory across every discovered web property.
• Watch for marketing microsites running admin interfaces on non-standard ports.

From DMARC monitoring platforms (Dmarcian, Valimail, Proofpoint)

• Aggregate reports (RUA) show every IP address sending email that claims to come from your domains.
• Forensic reports (RUF) detail messages that failed authentication: source, sending IP, recipient.
• Vendor send-stream mapping identifies the ESPs and marketing automation tools using your domains.
• Policy enforcement gaps surface the domains still at p=none with enough volume data to support moving to enforcement.

From CDN and WAF consoles (Cloudflare, Akamai, Fastly, AWS CloudFront)

• TLS configuration: protocol versions, cipher suites, and certificate status across every property.
• Security header enforcement: CSP, HSTS, and X-Frame-Options deployment status.
• Bot traffic ratio: heavy bot traffic on a marketing property signals scraping, credential-stuffing reconnaissance, or automated form abuse.
• WAF rule hit rates: which OWASP attack categories are being attempted against marketing properties.

From marketing automation platforms

• Form destination audit: export every form submission destination from HubSpot, Marketo, or Pardot and confirm each one is an approved, reviewed endpoint.
• Email sending domain list: every domain configured as a sending identity in your ESP is in scope for SPF, DKIM, and DMARC review.
• Webhook inventory: webhooks from marketing platforms into CRMs and other systems are data-flow risks that need review.