Data Processing Agreement

1. About this agreement

This Data Processing Agreement ("DPA") is between ShieldMarc Ltd ("ShieldMarc", "we", "us" or "our"), a company registered in England and Wales under company number 17352242 with its registered office at 66 Paul Street, London, EC2A 4NA, United Kingdom, and each customer that uses the ShieldMarc service under our Terms of Service ("you" or the "Customer").

This DPA forms part of the Terms and applies automatically to every customer. You do not need to sign anything. If you would like a signed copy for your records, email privacy@shieldmarc.com.

It sets out how we process personal data on your behalf, as Article 28 of the UK GDPR requires. It also meets Article 28 of the EU GDPR for customers that are subject to it.

2. Definitions

• Data protection law: the UK GDPR and the Data Protection Act 2018 and, where they apply to you, the EU General Data Protection Regulation (Regulation (EU) 2016/679, the "EU GDPR") and the national laws that supplement it.
• Customer Personal Data: the personal data we process on your behalf to provide the Service, described in Annex 1.
• Service: the ShieldMarc platform and services, as defined in the Terms.
• Sub-processor: a third party we engage to process Customer Personal Data.
• Controller, processor, data subject, personal data, personal data breach and supervisory authority have the meanings given to them in data protection law.

3. Our roles

You are the controller of Customer Personal Data, and we process it for you as your processor.

If you use the Service to look after domains for your own clients, for example as a managed service provider, you may be a processor for those clients. In that case we are your sub-processor. You are responsible for having your clients' authorisation to use us, and this DPA still governs the processing between you and us.

We are the controller of the personal data we need to run your account and bill you: account and team member details, sign-in and audit records, billing details and support requests. Our Privacy Policy covers that data, not this DPA.

You are responsible for making sure you may lawfully have us process Customer Personal Data, and that your instructions to us comply with data protection law.

We also combine the IP addresses and relay domains of servers seen sending email in all customers' reports to build a shared threat feed that warns every customer about abusive senders. For that limited purpose we act as an independent controller, relying on our legitimate interest in network and information security, as our Privacy Policy explains. The feed shows each customer an IP address or relay domain and how many organisations it affects, and never names another customer's domains.

4. Processing on your instructions

We process Customer Personal Data only on your documented instructions, including when we transfer it to another country (section 12). Your instructions are:

• the Terms and this DPA;
• your use and configuration of the Service, such as the domains you add, the reporting addresses you publish in your DNS records, the monitors, alert recipients and scheduled reports you set up, and the AI features your users choose to run; and
• any other written instructions you give us.

If UK law, or for EU customers the law of the EU or an EU member state, requires us to process Customer Personal Data in any other way, we will tell you before we do so, unless that law forbids it on important grounds of public interest.

We will tell you immediately if, in our opinion, an instruction infringes data protection law.

We do not sell Customer Personal Data and we do not use it for advertising.

5. Confidentiality

We make sure that everyone we authorise to process Customer Personal Data has committed to keep it confidential or is under a legal duty of confidentiality.

We do not disclose Customer Personal Data to anyone except our sub-processors under section 7, people you ask us to send it to (such as your alert and report recipients), other customers through the threat feed described in section 3, AbuseIPDB as described in Annex 3, or where the law requires it.

6. Security

We take the technical and organisational measures that Article 32 requires to protect Customer Personal Data, appropriate to the risk. Annex 2 lists the measures we have in place. We may change them over time, but not in a way that lowers the overall level of protection.

You are responsible for how you use the Service, for example keeping sign-in details safe and removing team members who should no longer have access.

7. Sub-processors

You give us general written authorisation to use the sub-processors listed in Annex 3.

We will give you at least 30 days' notice before we add or replace a sub-processor. We do this by updating the list on our website and emailing your organisation's account owners.

You may object to a change on reasonable data protection grounds by telling us before it takes effect. We will work with you in good faith to resolve your objection. If we cannot resolve it, you may end your subscription straight away, without penalty, and we will refund any fees you have prepaid for the period after it ends.

We impose on each sub-processor, by written contract, data protection obligations equivalent to those in this DPA. We remain liable to you for how each sub-processor meets them.

8. Helping you with data subject requests

Taking into account the nature of the processing, we help you, by appropriate technical and organisational measures where possible, to respond to people exercising their rights under data protection law, such as access, correction, erasure, restriction, portability and objection.

You can do some of this yourself in the Service, for example by removing an alert recipient or downloading the original file of an aggregate report. For anything else, open a privacy ticket or email privacy@shieldmarc.com.

If someone asks us directly to exercise their rights over Customer Personal Data and we can tell that it relates to you, we will pass the request to you without undue delay. We will not answer it ourselves unless you ask us to.

9. Helping you with security, breaches and impact assessments

Taking into account the nature of the processing and the information available to us, we help you meet your obligations under Articles 32 to 36 of the UK GDPR, and of the EU GDPR where it applies:

• Security: we keep the measures in Annex 2 in place and answer reasonable questions about them.
• Personal data breaches: we will tell you without undue delay, and in any case within 48 hours of becoming aware of a personal data breach affecting Customer Personal Data. We will email your organisation's account owners with the information you need for your own notifications to a supervisory authority or to the people affected. That information, as far as we know it, is: what happened; the categories and approximate numbers of people and records involved; the likely consequences; what we have done or plan to do; and who to contact. We will update you as more is known.
• Impact assessments and prior consultation: we will give you the information you reasonably need about the Service to carry out a data protection impact assessment, and to consult a supervisory authority where the law requires it.

10. Deletion and return of data

Cancelling a paid plan does not end the Service. Your organisation moves to the free Starter plan and keeps its data. For this DPA, the Service ends when your organisation is deleted.

Before then, you can take a copy of your data:

• download the original XML file of any aggregate report from the Email page;
• on the Professional and MSP plans and during the free trial, download reports as PDF and CSV files from Exports; and
• ask for a machine-readable export of your data by opening a privacy ticket or emailing privacy@shieldmarc.com.

An owner can delete the organisation from Settings. The deletion takes effect 30 days later. During those 30 days the owner can cancel it, and we email a reminder to an owner 7 days and 1 day before it happens. You can still ask for an export in this time.

When the 30 days end, our daily deletion job permanently deletes the organisation and everything it holds in our database, including its domains, monitors, alert recipients, branding and settings. It also deletes from our search store every report sent to the organisation's reporting address and the report data for every domain it claimed, and it deletes the copies of its original report emails and report files in our object storage. The only reports that stay are those about a domain another organisation also monitors, because they are that organisation's data too.

Copies of report emails we received before 18 October 2026 are not filed by organisation, so they are deleted when they are 365 days old, the limit that applies to all report data. Please remove our reporting addresses from your DNS records when you delete your organisation: reports that keep arriving at an old address are also deleted when they are 365 days old.

Our backups are encrypted and kept for up to 30 days, as 7 daily and 3 weekly copies. We do not edit backups to remove individual records, so deleted data has left every backup within 30 days of the deletion. Operational and security logs that can contain your domain names or organisation identifier are kept for up to 12 months.

If you want your data returned rather than only deleted, ask for an export before the 30 days end. After deletion we keep Customer Personal Data only as this section describes or where the law requires it.

11. Information and audits

We will make available to you the information you reasonably need to show that we meet our obligations under this DPA and Article 28.

Audits are remote by default. On request we will share our security documentation, answer reasonable security and data protection questionnaires, and take part in a remote review.

If you reasonably need more, you, or an independent auditor you appoint who is bound by confidentiality, may audit or inspect our compliance with this DPA. An audit takes place on at least 30 days' written notice, at your cost, and at a time and in a way we both agree, which may be remote. We will not unreasonably refuse or delay agreeing a time and manner. It may take place at most once in any 12 months, unless a supervisory authority requires it or it follows a personal data breach affecting Customer Personal Data.

The physical hosting facilities are covered by our hosting provider's own certifications and audit reports.

12. International transfers

Core Customer Personal Data is hosted in Germany (EU) by default. Dedicated UK hosting is available on request on an enterprise plan. EU-only AI routing is also available on request on an enterprise plan.

Some of the sub-processors in Annex 3 process Customer Personal Data outside the UK and EU. Cloudflare runs a global network, and its object storage, which keeps the copies of report emails, is not restricted to the EU. The AI providers process what is sent to them in the United States.

The EU countries, Germany included, are covered by UK adequacy regulations. Transfers of EU customers' data to us in the UK rely on the European Commission's adequacy decision for the UK while it is in force.

For any other transfer of Customer Personal Data out of the UK to a sub-processor, we use the UK International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses. For EU customers' data leaving the EU, we use the EU Standard Contractual Clauses. Where a provider is certified under the EU-US Data Privacy Framework and its UK Extension, we may rely on that certification instead.

If the UK International Data Transfer Agreement, the UK Addendum or the EU Standard Contractual Clauses apply to a transfer and conflict with this DPA, they prevail for that transfer.

13. How long this DPA lasts

This DPA lasts for as long as we process Customer Personal Data for you, including the deletion periods in section 10.

14. Order of precedence

If this DPA conflicts with the Terms of Service on a data protection matter, this DPA prevails. On everything else, the Terms apply.

15. Liability and governing law

Liability under this DPA is subject to the limitation of liability in the Terms, except where the law does not allow it to be limited.

As in the Terms, this DPA is governed by the laws of England and Wales, and the courts of England and Wales have exclusive jurisdiction over any dispute about it. Where the EU Standard Contractual Clauses apply to a transfer, their own governing law and jurisdiction clauses apply to them.

16. Changes and contact

We may update this DPA in the same way as the Terms. Changes to our sub-processors follow section 7.

For questions about this DPA, open a privacy ticket or email privacy@shieldmarc.com.

Annex 1: Details of the processing

Subject matter

Providing the Service to you: collecting and analysing the email authentication reports sent about your domains, and monitoring the domains, hosts and records you add.

Duration

For as long as you use the Service, and then until the data is deleted as set out in section 10. On every plan, report data is deleted automatically when it is 365 days old, counted from the date the report covers, and uptime check results after 90 days.

Nature and purpose

• Receiving the DMARC aggregate reports, DMARC failure (forensic) reports and TLS-RPT reports sent to the reporting addresses you publish, and keeping a copy of each report email as it arrived.
• Reading and storing those reports, and adding the reverse DNS name, approximate location and threat signals for each sending server's IP address.
• Showing the results in your dashboard, and using them for your alerts and scheduled reports.
• Checking the DNS records, certificates, websites and registration details of the domains and hosts you add, and recording the results.
• Sending alert emails and scheduled reports to the recipients you choose.
• Sending the relevant data to an AI provider when one of your users runs an AI feature.
• Storing, backing up, securing and deleting all of the above.

Types of personal data

• From aggregate reports: IP addresses of sending servers, with their reverse DNS names and approximate location; the domains used in the From header and the envelope; SPF and DKIM results; message counts; and the name and contact email address of the organisation that sent the report.
• From failure (forensic) reports: the IP address of the sending server; sender and recipient email addresses; the subject line and other message headers, which can include names; and the report email as it arrived, which some receivers send with the whole failing message attached.
• From TLS-RPT reports: IP addresses and hostnames of the sending and receiving mail servers, and the name and contact details of the organisation that sent the report.
• Monitoring data: the domain names, hostnames and URLs you add, and the DNS records, certificate details, registration details and uptime results we collect for them. These are rarely personal data, but can be where a domain, record or certificate identifies a person.
• Details you add: the email addresses of alert and scheduled report recipients, and the names, logos, contact lines and reply-to addresses you add to report branding or to client tags.
• AI requests: the questions your users ask Ask AI and the domain context sent with them, which can include report data such as sending-server IP addresses.

Categories of data subjects

• People and organisations who send email using your domains, and the operators of the mail servers that handle it.
• People who send email that impersonates your domains.
• Recipients of email sent using your domains, where a failure report names them.
• Staff of the organisations that send the reports.
• Your staff, clients and other people you add as recipients or name in report branding.
• People identified by a domain, record or certificate you monitor.

Annex 2: Technical and organisational measures

Access and separation

• Customer organisations are kept apart in our database by Postgres row-level security. The default database role for signed-in users' requests can read only the rows of that user's organisations. Scheduled jobs and some dashboard requests use a service role, and application code limits what they read to the right organisation.
• Report data in our search store is filtered by the application to each organisation's verified domains, and failure reports are shown only for verified domains.
• Each organisation has three roles: owner, admin and viewer. Billing changes, transferring the organisation, removing an owner or admin and deleting the organisation need an owner.
• Passwords are stored only as hashes, and sign-up and password-reset requests are checked with Cloudflare Turnstile.
• Alert recipients outside your organisation must confirm their address before they receive alerts, and scheduled reports can be sent only to email domains your organisation has verified.

Encryption

• Traffic between browsers and the Service is encrypted with TLS, and our HSTS header tells browsers to use HTTPS only.
• Offsite backups are encrypted with AES-256 before they leave our servers, under a passphrase only ShieldMarc holds, so our hosting provider cannot read them.

Hosting and network

• Core data is hosted on dedicated servers in Germany (EU).
• All public traffic passes through Cloudflare's edge network, which provides a web application firewall, bot scoring and DDoS mitigation. The application is reachable only through an authenticated tunnel.
• The host firewall denies inbound traffic by default and accepts only SSH and ping from the internet. SSH accepts keys only, brute-force attempts are banned automatically, and root cannot log in over SSH on the servers that run our virtual machines and the application.
• Security updates are installed automatically from the operating system's security channel.
• The server that runs our virtual machines keeps kernel-level audit logs of changes to accounts and access settings and of commands run as root.
• That server and the application server are checked daily for changed system files, rootkits and malware, with a full malware scan every week. Anything found is reported to our operator.
• Application containers run with no-new-privileges, a read-only root filesystem, CPU and memory limits, and network isolation for the services that store data.

Application security

• API endpoints are rate-limited per user and per source address, and repeated violations lead to temporary bans.
• State-changing requests are checked for cross-site request forgery, and domains and URLs you submit are checked against private and reserved address ranges before we connect to them.
• Most request bodies are size-capped and validated against typed schemas, and webhooks from our billing provider are signature-verified.
• Security headers, including HSTS, X-Frame-Options and Referrer-Policy, are set on application responses.

Development and testing

• Builds check our dependencies for known vulnerabilities, and automated pull requests are raised when a new advisory affects one.
• Every deployment image is scanned for vulnerabilities, and a software bill of materials is produced for the web application image.
• Two secret scanners check pushes to the main branch and pull requests, and a finding blocks deployment. The full repository history is scanned nightly.
• Static code analysis runs in continuous integration.
• Dynamic application security testing runs against production: an OWASP ZAP baseline scan twice a week and a Nuclei template scan once a week.
• Secrets are kept out of our code. The application reads them on the server at runtime, and most credentials our operational scripts use are held in a root-owned secret store.

Logging, backups and recovery

• Significant account actions are written to an audit log with the person and time and, for most, the IP address and user agent. Entries are kept for 12 months.
• The database and search store are backed up nightly and copied to encrypted offsite storage in the EU, kept for up to 30 days (7 daily and 3 weekly copies). A scripted procedure restores the Service from those backups.
• Failed backups are emailed to our operator, and failed security scans and security findings are reported to our operator.

Minimisation and retention

• For failure reports we index only the message headers, up to 8 KiB. The report email itself is kept as it arrived.
• Report data is deleted automatically after 365 days, and uptime check results after 90 days.
• AI features run only when a user starts one. Otherwise no Customer Personal Data is sent to an AI provider.
• Access to Customer Personal Data is limited to people we authorise, who are bound by confidentiality (section 5).

Annex 3: Sub-processors

These sub-processors process Customer Personal Data. The full list of every sub-processor we use, including those that handle only data we control, is in our Privacy Policy.

• Our hosting provider (Germany, EU: hosting and offsite backups): runs the dedicated servers, database, search store and queues that hold and process Customer Personal Data, and stores our encrypted offsite backups, which it cannot read. We give the provider's name to any customer on request.
• Microsoft (EU, email): hosts the mailbox that receives the reports sent to us, and delivers alert emails and scheduled reports to your recipients through the Microsoft Graph API.
• Cloudflare (global, edge network and storage): routes all traffic to the Service through its web application firewall, DDoS mitigation and the authenticated tunnel to our servers; keeps a copy of each report email and the report files it carries in R2 object storage; runs our uptime checks; and operates the AI Gateway that passes AI requests to the providers below.
• Google (US, optional AI features): runs Ask AI on the Email page through its Gemini API, only when one of your users uses it.
• Anthropic (US, optional AI features): a fallback provider for Ask AI, used only when one of your users runs it.
• OpenAI (US, optional AI features): receives the relevant record when one of your users runs Explain with AI on certain tools or the onboarding wizard's AI analysis.

AbuseIPDB (US) is not a sub-processor: it runs its own public IP reputation database as an independent controller. We send it the IP addresses of servers that send email as your domains, to check their reputation. Only when one of your users chooses to report an address does it publish a report, under our name, naming that IP address and the domain it sent email as.

Stripe processes billing details, which we control as described in our Privacy Policy. It does not process Customer Personal Data. Google Analytics runs only on our public website, with the visitor's consent, and does not receive Customer Personal Data either.

Support tickets are stored in a helpdesk we host ourselves on the same servers, so no helpdesk company receives them.