Glossary: the terms in a martech vendor review

Evidence labels

Every claim on a vendor profile carries one of six labels, strongest first. A label says how strong the source is, not whether the answer is good.

Verified

We measured it ourselves: TLS, DMARC, security headers, robots.txt.

Evidence found

A document issued by a third party, such as an auditor's report or a certificate.

Vendor commits

The vendor's binding document says so: privacy policy, DPA, terms or imprint.

Vendor states

The vendor's own page says so: a security, product or marketing page.

Conflicting

The vendor's sources disagree.

Not found

Not found in the pages we read. That is not a no. Ask for it in the demo.

Compliance & legal

SOC 2 (Type I and Type II)

An independent auditor’s report, under the AICPA’s Trust Services Criteria, on a service provider’s controls for security and, optionally, availability, processing integrity, confidentiality and privacy. A Type I report looks at whether the controls are suitably designed at one point in time; a Type II report also tests whether they worked over a period, usually several months to a year. It is an attestation report, not a certificate, and the report itself is normally shared only under NDA.

Where vendors publish it: A security or trust page, often with a SOC 2 badge; the report sits behind a request form.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

ISO/IEC 27001

The international standard for an information security management system. A certificate is issued by an accredited certification body after an external audit, covers a stated scope — which can be narrower than the whole company or product — and is kept current through regular surveillance audits. The scope statement tells you whether the product you are buying is inside it.

Where vendors publish it: A security or trust page, sometimes with the certificate as a download.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

GDPR

The EU General Data Protection Regulation (Regulation (EU) 2016/679), which governs how personal data of people in the EU is processed. Compliance is not a badge a vendor earns once, so “GDPR compliant” on a website is the vendor’s own statement. What a reviewer can check is the paperwork behind it: a DPA, a sub-processor list, and where data is stored.

Where vendors publish it: The privacy policy, a legal page, or a trust page.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

DPA (Data Processing Agreement)

The contract that Article 28 of the GDPR requires between a customer (the controller) and a vendor that processes personal data on its behalf (the processor). It sets out what the vendor may do with the data, its security measures, its sub-processors, how it helps with data-subject requests, and what happens to the data when the contract ends.

Where vendors publish it: A legal page, often a standard DPA to download or sign online.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

Sub-processor

A third party that a vendor uses to process its customers’ personal data — a cloud host, an email-delivery service, an AI model provider. Under the GDPR the vendor needs the customer’s prior authorisation, which is usually handled by publishing a list and notifying customers before it changes.

Where vendors publish it: A sub-processor page under legal or trust, sometimes with a change-notification sign-up.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

SCCs (Standard Contractual Clauses)

Model contract terms adopted by the European Commission that allow personal data to be transferred from the EU to a country without an adequacy decision. A vendor that stores or accesses data outside the EU usually relies on them, or — for certified US companies — on the EU–US Data Privacy Framework.

Where vendors publish it: The DPA or its annexes.

Data residency

Where a vendor stores customer data — and, as a separate question, where it processes it and from where people can access it. “EU hosting” can still mean that support staff or sub-processors outside the EU can reach the data, so ask about all three.

Where vendors publish it: A security, trust or hosting page; the DPA for the binding version.

Security

Trust center

A page, often run on a specialised platform, where a vendor collects its security and compliance material: certificates, audit reports, policies, sub-processor lists. Many are gated — documents are released after a request or an NDA — so the page and what it lists are public while the documents often are not. In our audits, whether a trust center exists is checked when we fetch it, along with its platform and whether it is gated: that it exists, not what it says. What its public pages say is read like any other vendor page; gated documents are not read.

Where vendors publish it: Usually at /trust or /security, or on a separate trust-platform domain.

Penetration test

An authorised, simulated attack on a system by independent testers, looking for weaknesses an attacker could exploit. Vendors rarely publish full reports; a public page usually says how often testing happens and that a summary or attestation letter is available on request.

Where vendors publish it: A security or trust page.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

Encryption in transit and at rest

In transit: data is encrypted while it moves over a network, normally with TLS. At rest: data is encrypted where it is stored — disks, databases, backups. Useful follow-ups are which algorithms, who holds the keys, and whether you can bring your own key.

Where vendors publish it: A security page or the technical documentation.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

MFA (multi-factor authentication)

Signing in needs a second factor besides the password, such as an authenticator app or a hardware key. For a procurement review the question is whether it can be enforced for every user in your account, not merely offered.

Where vendors publish it: A security page or the admin documentation.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

SSO and SCIM

Single sign-on lets your staff log in to a vendor’s product through your own identity provider, usually over SAML or OpenID Connect. SCIM is a standard that lets that identity provider create and remove accounts automatically, so a leaver loses access everywhere at once. Both are often limited to higher plans.

Where vendors publish it: The pricing page and the admin or identity documentation.

Incident response

A documented process for detecting, containing and communicating security incidents. Under the GDPR a processor must tell its customer about a personal-data breach without undue delay; what a reviewer looks for is that commitment and its timeframe, usually written into the DPA.

Where vendors publish it: A security page, a status page, or the DPA.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

TLS grade

TLS (Transport Layer Security) encrypts the connection between a browser and a website. Our TLS grade is based on the TLS protocol version the site negotiates, graded A to F: TLS 1.3 is an A, TLS 1.2 a B, and older versions lower. A failed handshake, for example because of an invalid certificate, is an F; a site we cannot reach at all gets no grade rather than a bad one.

In our audits: Measured by our weekly external scan, not taken from the vendor’s pages.

Security headers

Instructions a website sends with every page that tell browsers to apply protections — for example Strict-Transport-Security (always use HTTPS), Content-Security-Policy (which scripts may run) and X-Content-Type-Options. A security-headers grade sums up which of them a site sends.

In our audits: Measured by our weekly external scan, not taken from the vendor’s pages.

DMARC

A DNS record at _dmarc.<domain> that tells receiving mail servers what to do with email that fails sender checks. A policy of p=quarantine or p=reject means mail spoofing the domain is actually stopped; p=none only reports it. We count quarantine or reject as enforced.

In our audits: Measured by our weekly external scan, not taken from the vendor’s pages.

AI governance

Customer data used for training

Whether a vendor uses the data you put into its product to train or improve AI models — its own, or a model provider’s. It is the one check where the answer reviewers usually hope for is “no”. Read the exact wording: “not used for training” may cover only some models or some plans, and an opt-out is not the same as a default of no.

Where vendors publish it: The privacy policy, the DPA, or an AI or data-use policy.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

EU AI Act risk class and role

The EU AI Act (Regulation (EU) 2024/1689) sorts AI systems by risk: prohibited practices, high-risk systems with strict obligations, systems with transparency duties such as chatbots and generated content, and minimal-risk systems. It also assigns duties by role — provider, deployer, importer, distributor — with separate rules for general-purpose AI models. A risk class or role on a vendor’s site is the vendor’s own assessment.

Where vendors publish it: An AI transparency, trust or legal page.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

AI output labelling

Telling people that they are dealing with an AI system, or that content was generated or altered by AI. Article 50 of the EU AI Act makes this an obligation for certain systems.

Where vendors publish it: An AI transparency page or the product documentation.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

Human in the loop

A design in which a person reviews, approves or can override an AI system’s output before it takes effect. How much the person actually checks varies widely, so look for what exactly is reviewed and by whom.

Where vendors publish it: The product documentation or an AI policy.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

Responsible AI policy

A published policy on how a vendor builds and uses AI: principles, governance, risk assessment, and who is accountable. It is a statement of intent, most useful when it names concrete practices.

Where vendors publish it: An AI, ethics or trust page.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

Model documentation

Model cards, changelogs or release notes saying which AI models a product uses and when they change — so a customer can notice when the model behind a feature has been swapped.

Where vendors publish it: The documentation, a changelog, or an AI transparency page.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

Reliability

Uptime SLA and status page

A service level agreement commits the vendor to an availability target — for example 99.9% a month — usually with service credits if it is missed. A status page shows current and past incidents. A status page without an SLA is information, not a commitment.

Where vendors publish it: A legal or SLA page and a status page, often on a status subdomain.

In our audits: Read from the vendor’s own public pages during a deep audit, with the source page linked.

Crawling and AI access

robots.txt and AI-crawler rules

A file at the root of a website that tells crawlers which paths they may fetch. Sites increasingly add rules for AI crawlers by name, such as GPTBot or ClaudeBot. It is a request that well-behaved crawlers honour, not an access control.

In our audits: Measured by our weekly external scan, not taken from the vendor’s pages.

TDM opt-out

Under Article 4 of the EU Directive on Copyright in the Digital Single Market (2019/790), rights holders can reserve their content from text and data mining in a machine-readable way, for example in robots.txt or with the TDM Reservation Protocol. We read these signals before we crawl, and if a site disallows AI crawlers we do not scrape it.

In our audits: Measured by our weekly external scan, not taken from the vendor’s pages.

llms.txt

A proposed convention (llmstxt.org): a markdown file at /llms.txt that gives language models a short, curated index of a site. Support among AI search engines is limited and uneven, so having one says more about a vendor’s attention to AI access than about its reach.

In our audits: Measured by our weekly external scan, not taken from the vendor’s pages.