# The 8 Security Documents Your Direct Mail Vendor Should Produce in 48 Hours > A practical checklist of the documents enterprise procurement teams expect any direct mail vendor to deliver as part of standard vendor security review — and how to read each one. **Author:** Shawn Burst **Published:** 2026-05-18 **Category:** Vendor Security **Reading time:** ~6 min **Tags:** Vendor security, Procurement, Compliance, Documentation, Buyer's guide Canonical URL: https://directmail.io/blog/direct-mail-vendor-security-documents/ --- Vendor security review used to be a one-line question on a purchase order. Today, for any marketing platform with meaningful contract value, it's a structured document review handled by a security analyst with a checklist. The vendors who close enterprise deals are the ones who can produce that document set within 48 hours of an NDA execution. The vendors who can't, drop out of the pipeline. Here are the eight documents your direct mail vendor should produce, what each one tells you, and what red flags to watch for. ## 1. The SOC 2 Type 2 attestation report What it is: an independent auditor's report attesting that the vendor's security controls operated effectively across a 6-12 month observation period. Shared under NDA. What it tells you: the vendor has been operating like an audited company for the past year. The five trust service criteria — Security, Availability, Processing Integrity, Confidentiality, Privacy — show which areas were in scope. The findings section reveals where controls failed and how the vendor responded. Red flags: Type 1 only (with no plan for Type 2), expired report (>14 months old), Security-only scope when the vendor handles confidential data, zero exceptions reported (typically means the report has been redacted or the audit wasn't rigorous), an unfamiliar auditing firm. For a deeper breakdown of how to read a Type 2 report, see [SOC 2 Type 1 vs Type 2 explained](/blog/soc-2-type-1-vs-type-2-explained/). ## 2. The Business Associate Agreement (BAA) — for HIPAA-covered workflows What it is: a contract required under HIPAA when a business associate (the vendor) handles Protected Health Information on behalf of a covered entity (the customer). What it tells you: the vendor has the legal posture and operational maturity to handle PHI. The BAA defines permitted uses, breach notification timelines, subcontractor requirements, and the right to audit. Red flags: vendor doesn't offer a BAA, BAA is offered only at extra cost, BAA template hasn't been updated since 2013, vendor pushes back on standard BAA terms (specifically the breach notification timeline and the audit rights), vendor's BAA excludes liability for their subprocessors. ## 3. The Data Processing Addendum (DPA) What it is: a contractual addendum defining the vendor's role as a data processor under privacy frameworks (GDPR, CCPA, similar state laws). Defines processing purposes, data categories, security commitments, subprocessor management, and data subject rights handling. What it tells you: the vendor takes its data processor role seriously. The DPA also defines the vendor's commitments around international data transfers — typically with Standard Contractual Clauses (SCCs) attached as an annex. Red flags: no DPA available, DPA only available for enterprise customers (small-customer privacy is the same as enterprise privacy), DPA excludes standard processor obligations, no SCC annex for European data flows. ## 4. The subprocessors list What it is: a current list of third-party services the vendor uses to deliver the platform. Cloud infrastructure (AWS, GCP, Azure), data partners (USPS NCOA providers, identity-resolution vendors, address-validation services), payment processors, communication providers, observability tooling. What it tells you: who else has access to your data. Each subprocessor is a separate attack surface. The list reveals whether the vendor's stack is mature and whether they're using reputable subprocessors or sketchy ones. Red flags: vendor refuses to provide the list, list is short and obviously incomplete, list includes subprocessors with no public security posture, no notification commitment for material subprocessor changes, customer data flows to jurisdictions the customer didn't expect (e.g., outside the US or EU when the customer is US-based). ## 5. Security questionnaire responses What it is: completed responses to standard security questionnaires — SIG (Standardized Information Gathering, ~700 questions), CAIQ (Cloud Security Alliance's Consensus Assessments Initiative Questionnaire, ~200 questions), or a custom enterprise questionnaire. What it tells you: the vendor's posture across hundreds of specific control areas — identity and access management, network security, endpoint security, data classification, change management, incident response, business continuity, vendor management. Reveals depth and consistency of the security program beyond what SOC 2 captures. Red flags: vendor can't complete a SIG within two weeks, responses are vague ("we follow industry best practices" with no specifics), responses contradict the SOC 2 report, responses note "not applicable" for controls that obviously apply. ## 6. The penetration test summary report What it is: a summary of findings from the vendor's most recent third-party penetration test. Typically annual, sometimes more frequent. Tests both the application layer and the infrastructure layer. What it tells you: how the vendor's systems hold up against a skilled adversary. Reveals the rigor of the testing methodology and how quickly the vendor remediates findings. Red flags: no annual penetration test, pen test was performed by an internal team (not independent), summary report has no critical or high findings ever (real apps always have some, even briefly), remediation timelines are vague ("we'll fix that soon"), testing scope excludes major parts of the platform. ## 7. The incident response and breach notification policy What it is: a documented policy defining how the vendor detects, contains, investigates, and notifies on security incidents. Includes the breach notification timeline contractually committed to customers. What it tells you: how prepared the vendor is to handle the worst case. Reveals whether the vendor has done tabletop exercises, who's on the response team, and how customers learn about an incident affecting their data. Red flags: no documented policy, notification timeline is "as soon as practical" instead of a specific commitment (industry standard is 24 hours from discovery), no playbook for customer communication, vendor has never run a tabletop exercise. ## 8. The encryption and key management documentation What it is: documentation of how the vendor encrypts data in transit, at rest, and in backups — including the key management practices (where keys are stored, how they're rotated, who has access). What it tells you: whether the vendor's encryption posture is real or marketing. "AES-256 at rest" is meaningless if the keys are stored in the same database as the encrypted data. Red flags: TLS 1.0 or 1.1 still supported (should be 1.2+ minimum, 1.3 preferred), data at rest is "encrypted by the cloud provider" only (this isn't a real customer-protective control), keys aren't rotated on a defined schedule, no separation between encryption key custody and data custody, no answer on how the vendor handles encrypted-backup recovery during incident response. ## How DirectMail.io handles vendor security review DirectMail.io's enterprise security packet includes all eight documents and is delivered within 48 hours of mutual NDA execution. The packet covers: - **SOC 2 Type 2 attestation report** — full five-criteria scope, audited annually - **BAA** — standard template for HIPAA-covered customers - **DPA + SCC annex** — for GDPR-regulated data flows - **Current subprocessors list** — with material-change notification commitment - **SIG response** — or custom enterprise questionnaire if the customer prefers - **Annual penetration test summary** — independent third-party firm - **Incident response policy** — including the contractual 24-hour breach notification commitment in Section 3.10 of the Terms of Service - **Encryption and key management documentation** — TLS 1.2+ in transit, AES-256 at rest, key management practices documented Most enterprise security reviews complete within 2-3 weeks of intake including a security review call with the platform infrastructure team. The full posture is documented on the [security page](/security). ## What good looks like, in one sentence A vendor with a real security program can produce these eight documents in two business days, every time, without hesitation. A vendor whose security program is mostly marketing will take two weeks to assemble a partial set with vague answers and missing pieces. The difference shows up in the response time, not in the marketing pages. ## Related reading - [SOC 2 Type 2 for Marketing Platforms: What Procurement Asks, and What "Yes" Actually Means](/blog/soc-2-type-2-marketing-vendor-procurement/) - [When a Direct Mail Vendor Has a Breach: Who's Actually Liable?](/blog/direct-mail-vendor-breach-liability/) - [SOC 2 Type 1 vs Type 2: The Difference That Determines Whether Your Vendor Is Actually Audited](/blog/soc-2-type-1-vs-type-2-explained/) - [How to Choose a Direct Mail Platform: 14 Questions That Actually Matter in 2026](/blog/how-to-choose-direct-mail-platform/) [Book a security review call with DirectMail.io](/product-demo) or [request the security packet under NDA](/contact).