Security you can trust, not just claim.

ShieldMarc is UK based. By default our core infrastructure, databases and monitoring pipelines run inside the European Union. All customer monitoring data is stored and processed within the EU under GDPR and UK data protection law. The categories of sub-processor (cloud database, infrastructure, offsite backup, email delivery, edge network, payments, AI providers) are set out in our Privacy Policy. Named providers, specific regions and a data-flow diagram are disclosed under NDA on request as part of any DPIA or procurement questionnaire.

AI analysis is always on-demand and never automated. It fires only when an operator clicks an AI button (Explain with AI on a tool result, AI analysis on a DMARC report row, or deep domain review). No background inference, no scheduled AI jobs, no silent outbound calls. The signal layer, enforcement engine and alerting all run deterministically without AI involvement.

Deep reasoning (DMARC report analysis, threat-feed review, full domain posture review) is a paid-tier feature and runs on a frontier Anthropic Claude model. Free public tool explainers run on smaller, cheaper models so the free tier can stay genuinely free. We do not pin a specific Claude model version on public pages because it changes with the SDK; the current model in use is documented to procurement on request as part of any DPIA. When AI is invoked, the relevant record is sent to the model provider under API-only data processing terms that prohibit training on customer data and retain input for short-term abuse monitoring only. By default these providers process the request in the United States. The providers are listed in our Privacy Policy.

For organisations with strict data residency requirements we offer on request:

• Dedicated UK hosted environments for customers requiring UK data residency.
• EU AI routing that routes AI-assisted features to EU-hosted model endpoints instead of the default US providers.

Both are available to enterprise customers on custom pricing. Contact sales to discuss your requirements.

Public ingress is tunneled through a managed edge network. Origin servers have no publicly reachable inbound ports beyond the tunnel itself, so the application is not directly exposed to the open internet.

All data in transit is encrypted using TLS 1.3. Data at rest is encrypted using AES-256 across all storage layers.

Payment data is handled exclusively by our PCI-compliant payment processor. Card numbers, CVVs and banking details never touch ShieldMarc servers. We store only tokenised billing references.

Every customer organisation is isolated at the database layer using enforced row-level access controls. Every query is automatically scoped to the authenticated tenant by the database engine itself, not application code.

Cross-tenant data access is not possible by construction. No misconfiguration at the application layer can expose one tenant's data to another.

ShieldMarc uses three roles within each organisation:

• Owner: Full access. Organisation transfer, billing, member deletion.
• Admin: Can manage domains, invite members and configure modules.
• Viewer: Read-only access to monitoring data and reports.

Owner-only actions, including subscription changes, organisation transfer and member removal, require owner authentication and are not delegatable.

Every significant action is written to an immutable audit log with actor identity, timestamp, IP address and user agent. Audit log records are write-only at the database layer (no update or delete policy exists) and can be exported to owners on request via a security ticket.

ShieldMarc is primarily a machine-data platform. We process domain, DNS, certificate and DMARC report data, not end-user correspondence. That keeps the personal-data surface area deliberately small.

The only personal data we hold:

• Your account and team-member email addresses, for login, invites and notifications.
• Authentication and audit log entries, including IP address and user agent for each significant action.
• In the rare event that receivers send them, DMARC forensic (RUF) report headers. Major mailbox providers like Google, Microsoft and Yahoo do not send RUF reports by default, so this set is empty or near-empty for most customers. Only headers are retained, never body content.

What we never store: email body content, payment card data (tokenised by our PCI-compliant payment processor), and any personal data relating to your end users.

Monitoring data we do store: domain names, DMARC aggregate report data (source IPs, pass/fail counts, no message content), SSL certificate snapshots, DNS record snapshots, SPF/DKIM verification results, and uptime check results.

Retention: your data is retained for the duration of your subscription plus 30 days after cancellation, giving you time to export anything you need. After 30 days, all organisation data is permanently deleted.

GDPR: ShieldMarc is the data controller for all customer data. You have the right to access, correct and delete your data at any time. To request deletion, open a privacy ticket.

ShieldMarc infrastructure is monitored continuously across application and database layers. We target high availability and receive automated alerts for any degradation.

In the event of an incident affecting customer data or monitoring accuracy, affected customers will be notified within 72 hours via the email address on their account.

No formal SLA is published at this time. MSP customers should contact us to discuss contractual availability requirements.

Public status page: a public status page showing live availability, incident history and scheduled maintenance is on our near-term roadmap. Until it launches, open a security ticket to request recent availability figures.

ShieldMarc applies automated security controls across the full development and deployment lifecycle, and layered runtime defences in production. Specific tools and vendors are not listed publicly.

Build and release pipeline

• Dependency vulnerability scanning: Every build checks the full dependency tree against known CVE feeds, and automated pull requests are raised when new advisories affect a dependency we use.
• Container image scanning: Every deployment image is scanned for OS and library vulnerabilities, and a Software Bill of Materials is generated for each release.
• Secret scanning: Pre-commit and continuous-integration checks block credentials, API keys and tokens from being committed or merged.
• Code review: Production changes are reviewed against a documented checklist before release.

Edge and transport

• WAF, bot management and DDoS mitigation: All public traffic passes through a managed edge network providing web application firewall, bot scoring and DDoS mitigation before requests reach the application.
• Tunneled origin: Application servers are reachable only via an authenticated edge tunnel. No public inbound ports are exposed on the origin host.
• Security headers: Content Security Policy with per-request nonces, HSTS with preload, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy are enforced on all application responses.

Application runtime

• Rate limiting and abuse protection: API endpoints are rate-limited per identity and per source address. Repeated limit violations trigger temporary bans across the full API surface.
• CSRF protection: State-changing requests are validated against browser-origin signals before reaching handler logic.
• SSRF protection: User-supplied domain and URL inputs are validated against private, loopback, link-local and reserved IPv4 and IPv6 ranges before any outbound request.
• Signed webhook verification: Inbound webhooks from billing and auth providers are signature-verified and replay-protected with idempotency deduplication.
• Input validation: All API request bodies and query parameters are validated against typed schemas at the handler boundary.

Host and container hardening

• Host firewall: Default-deny inbound firewall with administrative access restricted to operator source addresses. Brute-force attempts are detected and banned automatically.
• Patching: Security updates are applied automatically from the distribution security channel.
• Host intrusion detection: The host runs continuous kernel-level audit logging on identity, privileged execution, kernel module and container-runtime events, daily file integrity checks, and daily rootkit and malware scans.
• Container hardening: Application containers run with no-new-privileges, a read-only root filesystem, restricted writable mounts, CPU and memory limits, and network isolation for stateful services.
• Administrative access: Password authentication is disabled, root login is disabled, and administrative sessions are key-only with verbose audit logging.

If you discover a security vulnerability in ShieldMarc, please report it responsibly via our security disclosure form with a description of the issue and steps to reproduce. We acknowledge submissions within 24 hours.

We target a 5 business day initial response. We ask that you:

• Do not access or modify data belonging to other customers.
• Do not publicly disclose the vulnerability before we have had a chance to address it.
• Act in good faith throughout the disclosure process.

We do not currently operate a formal bug bounty programme, but we are grateful to researchers who help us improve security.

ShieldMarc does not currently hold third-party security certifications. We would rather tell you that openly than imply otherwise. Formal certifications (starting with Cyber Essentials, then SOC 2 or ISO 27001 depending on customer demand) are a first-order goal as the business scales, and the engineering posture is already being built with those frameworks in mind.

What we already do: the controls described on this page (encryption, tenant isolation, role-based access, immutable audit logging, minimal personal-data handling, incident response, WAF and DDoS mitigation, dependency and container vulnerability scanning, secret scanning, tunneled origin with no public inbound ports) are the same ones a formal certification would assess. They are in production today, not on a roadmap.

For vendor assessments, DPIAs or public sector procurement questionnaires we provide tailored documentation on request. Contact sales with the framework or questionnaire you need to complete and we will respond with the relevant evidence.