I would not approve a self-service vendor until its controls, data handling, and contract terms meet your requirements. Before signing, tie each requirement to proof, a signed obligation, and a named owner. Set measurable terms - such as incident notice within 24 hours of awareness - rather than accepting vague promises.
For leadership teams accountable for EBITDA and enterprise value, I would use these 8 checks to assess downtime, data exposure, and exit costs:
- Certifications and attestations: Does the report cover your purchased features, subscription tier, and hosting region?
- Audit support: What documents, response deadlines, and review rights will the vendor provide?
- Data protection: How does the service control access, encrypt data, limit AI use, and delete copies?
- Breach response: When will you receive notice, updates, recovery results, and a root-cause report?
- Subprocessors: Who handles your data, under what terms, and what happens if you object to a change?
- Data location: Where are data, backups, keys, and staff access permitted?
- Security testing: What gets tested, how are findings fixed, and who verifies the fixes?
- Service and exit terms: What remedies, exports, transition support, and deletion proof does the contract require?
My decision rule is simple: a policy is not a contract commitment. <u>Resolve gaps before signing</u>, or document the mitigation, deadline, and executive acceptance of the remaining risk.
Self-Service Vendor Compliance: 8 Checks Before Signing
Cloud Vendor Security Assessment: The CISM Checklist for 2026
sbb-itb-97f6a47
Set Your Data and Compliance Requirements
Set the compliance baseline before comparing vendors. Agree on requirements for your portal, chatbot, or automated account workflow before contacting providers. Bring procurement, legal, privacy, security, IT, and operations together to draft a requirements brief covering features, users, workflows, budget, and service levels. Assign 1 owner to approve it.
Document each self-service integration’s data exchanges, permissions, authentication, and sync frequency. Specify whether it can only read data or also modify records. Include support access, logs, backups, retention periods, and exit requirements.
Separate personal information, protected health information (PHI), and payment-card data. Personal information can include names, email addresses, and employee identifiers. PHI is individually identifiable health information handled for a HIPAA-covered entity or business associate. Payment-card data can include cardholder data or sensitive authentication data and may trigger PCI DSS obligations.[1][2][3] Use redacted sample records to show what each category contains.
Have counsel map applicable U.S. federal laws, state privacy and breach-notification laws, industry requirements, and customer contract obligations. If a vendor will create, receive, maintain, or transmit electronic PHI, determine its business-associate status and require a HIPAA-compliant business associate agreement (BAA) before granting access. Encryption does not remove that requirement simply because the provider cannot decrypt the data.[2][5] Treat required agreements and prohibited processing locations as pass/fail conditions.
Assign owners for configuration, access approvals, monitoring, incident response, retention, and deletion. Draw a clear line between the vendor’s responsibility to secure its service and your responsibility to use it correctly. No certification covers every law, and a BAA does not replace your HIPAA risk analysis.[4]
Make each mandatory requirement a testable acceptance criterion, with a named reviewer and required evidence. Use these criteria to screen each vendor’s answers to the 8 questions below.
1. Which Certifications and Attestations Cover the Service?
Verify that the evidence covers the service you are buying. Request the current SOC 2 Type II report and check the audit period, scope, systems covered, Trust Services Criteria, exceptions, and customer-owned controls. SOC 2 is an attestation, not a certification. Type II tests operating effectiveness over a period; Type I tests control design at a point in time.[8][9] Use these checks to assess whether the vendor can support your audit and review process.
Compare the audit end date with your signing date. If there is a gap, request a vendor bridge letter, details of material changes, control incidents and remediation since the audit period ended, and the next Type II examination date.[8][9]
Obtain the ISO/IEC 27001 certificate. Confirm its issuer, dates, and standard edition, then verify that its scope covers the vendor’s legal entity, product, production environment, and the locations you will use.[6][7] These documents define the evidence you should expect during audits and compliance reviews.
Require a signed BAA before granting access to PHI. HHS recognizes no private HIPAA certification.[10][11] For payment-card services, request the current PCI DSS Attestation of Compliance. Confirm the validated service environment and which controls your team still owns.[1]
Review confidential reports or scope documents under NDA. Record exclusions and customer-owned controls against your acceptance criteria. Reject evidence that excludes the self-service features you are buying. Keep the report scope and exclusions available for the audit-support discussion in the next question.
2. What Support Do You Offer for Audits and Compliance Reviews?
Request the vendor’s audit-support package before signing. Once the assurance-report scope is clear, test whether the vendor can support audits of the self-service service you’re buying. Request current security and privacy policies, business-continuity documentation, and a recent penetration-test summary that covers scope, findings, and remediation status. Map each document to the product, hosting environment, APIs, admin tools, support systems, regions, and subprocessors in scope.
Ask whether the vendor completes SIG, CAIQ, or a customer security questionnaire. Require explanations for N/A answers, and record the version, date, reviewer, and supporting evidence. Questionnaires organize diligence; they don’t replace independent evidence.
Get the follow-up process in writing. Confirm the audit-support contact, response-time targets, escalation path, and materials available under NDA. Request a redacted audit package with an evidence index, request log, and response timeline. For regulator-mandated or legally required reviews, confirm legal review, preservation of logs and retained records from self-service workflows and support systems, cooperation, and prompt customer notification when legally permitted.
Then review the audit clause. Check advance notice, frequency and duration limits, remote versus on-site access, auditor qualifications, and fees. Determine whether the vendor can substitute existing reports for an audit and how it addresses material gaps. Require exceptions for legally mandated reviews, fee approval requirements, and clear terms on who pays when an audit finds a material vendor control failure.
Put evidence-delivery deadlines and follow-up remediation obligations in the agreement. Confirm that audit support covers relevant hosting providers and subprocessors, with separate evidence required when direct access is unavailable. A trust center page is not a contractual commitment.
3. How Do You Protect Data Across Self-Service Features?
Audit evidence is only the starting point. Verify that the controls work in every self-service feature. Map each feature’s data path from collection through deletion across chat, search, ticketing, knowledge bases, attachments, APIs, browser sessions, analytics, and admin consoles. Track content, credentials, metadata, transcripts, queries, files, responses, and logs. Separate production, test, telemetry, diagnostic, and derived data.
Require TLS 1.2 or higher for web connections in every feature in scope.[13][14] Verify encryption for databases, caches, logs, search indexes, and backups. Check key ownership, rotation, revocation, and staff access to decrypted data. Request architecture evidence of server-side tenant checks that prevent cross-customer access in search and AI features.
Verify SSO, enforced MFA, least-privilege access, and SCIM provisioning and deprovisioning within the self-service environment. Confirm whether disabling a user ends active sessions and removes service-account access. Vendor support access must be time-limited. Request a sample log with the actor, timestamp, tenant, action, resource, and result. Check that logs cover exports, permission changes, API activity, and support access, with tamper protection and SIEM export.
Set retention and deletion timelines for each data type. Require usable exports that include attachments, metadata, and permissions. Deletion must cover replicas, caches, indexes, subprocessors, backups, embeddings, and analytics - not just the original ticket.[12] Document the maximum backup-retention period and safeguards against restoring deleted records. Before signing, test the controls with synthetic data: create a ticket, search for and export it, revoke access through SCIM, then delete it and compare the results with the documentation.
Assess AI features separately from training, testing, analytics, and manual review. Require explicit authorization before customer content is used to train shared models. Verify prompt and response retention, model-provider access, redaction, and the ability to disable AI in the product. A no-training promise does not address retention, support access, or model-provider use. Make sure these restrictions, along with required SSO, SCIM, logging, and key-management controls, apply to the contracted tier.
4. How Do You Handle Breaches and Notify Customers?
Test the vendor’s response when data-protection controls fail. Policies alone won’t tell you how the vendor will contain an incident, notify your team, or restore service.
Request the incident-response plan for the self-service portal, APIs, integrations, support channels, and administrative tools. It should cover detection, containment, recovery, log and artifact preservation, escalation, and post-incident review. Ask for tabletop or simulation results with redacted findings and corrective actions. Require a 24/7 escalation path with an emergency phone number, named roles, backup contacts, and critical-incident response times.[17][18]
Put notification deadlines in the contract. Define event, security incident, and breach, and tie notice requirements to suspected compromise, availability loss, and subprocessor incidents. An internal 1-hour investigation target is not a customer-notification deadline. Replace “promptly” with a fixed deadline, such as notice within 24 hours after awareness, and define when awareness begins.
The initial notice should separate known facts from open gaps. Require the incident time, affected services, data categories, scope, containment status, customer actions, and a contact. Set update intervals, such as every 24 hours during a critical incident and whenever material facts change. Assign responsibility for regulatory and individual notices. U.S. requirements vary by state, sector, and data type.[15]
Require forensic cooperation and preservation of relevant evidence. Set a preliminary report deadline of 10 business days after containment, plus a deadline for the final root-cause report. The final report should identify control failures, customer impact, corrective actions, owners, and completion dates. An unfinished investigation must not delay initial notification.[16][17]
Verify recovery performance, not just recovery targets. Review restoration procedures and tested recovery-time objectives (RTOs) and recovery-point objectives (RPOs). A 4-hour RTO means restoration within 4 hours; a 15-minute RPO means no more than 15 minutes of data loss. Request restore-test results showing usable data, backup integrity, and protection against reinfection. Confirm whether those targets are enforceable commitments or internal goals.
5. Which Subprocessors Handle Our Data?
A vendor’s approval does not clear its subcontractors. Request a dated, version-controlled register of every third party that stores, accesses, transmits, or processes customer data. It should identify each legal entity, its service and processing purpose, data categories, customer-data access level, and storage and access locations. Include hosting, support, email, analytics, backups, AI services, and any further subcontractors. Map each provider to the data it receives and the optional features you can disable.[19][20] Use this register to trace where customer data can move. The next question checks the vendor’s own storage, processing, and access locations.
For AI subprocessors, get written answers about model training, prompt and output retention, and human review. Check those uses against your contract’s data-use limits and confirm whether you can disable them. U.S. hosting does not mean access and processing stay in the U.S.
Separate the vendor’s controls from outsourced controls. Request assurance reports for material subprocessors, covering scope, report period, exceptions, services, and regions. Check whether the vendor’s SOC 2 report includes or excludes subprocessor controls. Ask how the vendor vets providers and reassesses their risks.[21][22] Missing evidence is a contract issue, not just a diligence gap.
Require contract flow-downs for confidentiality, security, breach cooperation, audit evidence, data-use limits, cross-border transfers, and data return or deletion. Where GDPR applies, Article 28 requires appropriate downstream obligations while keeping the primary processor responsible.[23][24]
Put change notices and objection rights in the contract. Include the register and update process in the agreement. Require advance written notice of changes to providers, locations, and data uses. Define the objection deadline, review process, and remedies: mitigation, an alternative configuration, or termination without penalty if the issue remains unresolved. A webpage update, or a right to object without a remedy, is not enough.[19][20] Verify the disclosed locations against the vendor’s actual data storage and access setup.
6. Where Do You Store, Process, and Access Our Data?
Require a data-location matrix, not a “U.S.-hosted” label. A disclosed subprocessor can still allow access from a prohibited location. For production data, backups, logs, telemetry, disaster recovery, support records, and encryption keys, require the cloud region, country, operating legal entity, and every country from which staff may access them.
Separate physical storage from legal jurisdiction. A U.S. cloud region may be operated by a multinational provider subject to other countries’ laws. Verify the vendor’s answers against replication diagrams and regional architecture documentation. Ask where encryption keys are generated, stored, backed up, and accessed, and whether vendor staff can decrypt or read your data. Confirm customer-managed key options, access revocation, and recovery procedures.[26] Encryption alone does not remove geographic storage restrictions.[29] Check that access, backup, and support locations match the contract.
Require a documented basis for cross-border transfers and remote access. The vendor should identify the applicable transfer mechanism and supporting safeguards. Where GDPR applies, Standard Contractual Clauses can provide transfer safeguards.[25] Require documentation of any additional safeguards needed.[27][28] For government, law enforcement, or national security requests, require procedures covering legally permitted notice, review and challenge of overbroad demands, minimum necessary disclosure, and delayed notice once a notification restriction ends.[30]
Make location limits enforceable. The agreement should separately define permitted locations for storage, processing, staff access, backups, disaster recovery, and key management. Regional restrictions must cover support tools and metadata, not just the primary database. Require evidence-review rights, advance notice of location changes, and approval or objection rights for new storage or processing locations. Include migration assistance or termination rights if the vendor breaches those limits.
At termination, specify the export format, download window, deletion deadline for active systems, and backup-erasure schedule. These requirements should cover all copies and derived data across all permitted locations. Require a deletion attestation, document any retention exceptions, and keep retained copies isolated.
7. How Do You Test Security and Fix Vulnerabilities?
Verify that security testing covers the live self-service service you’re buying, not just the vendor’s corporate network. Audit reports alone aren’t enough. Request the date, tester qualifications, methodology, and scope of the latest independent penetration test. Check coverage of the purchased portal, production application, admin console, tenant isolation, authentication and authorization, file uploads, integrations, public endpoints, APIs, chatbot or AI features, and other self-service workflows. A suitably redacted executive summary or findings list is acceptable. Each finding should identify the affected component, severity, remediation status, and retest result.[32]
Require SAST, DAST, secrets detection, and dependency reviews throughout development, including direct and transitive dependencies. Ask which findings block releases, how often the vendor scans infrastructure and containers, and whether material changes or new vulnerabilities trigger retesting. API tests should cover object-level authorization and rate limits. Chatbot tests should cover prompt injection, cross-tenant data leakage, and unauthorized tool calls in the service you’re buying, not just the vendor’s default demonstration environment.[34][36][37]
Set measurable remediation deadlines. Targets should include mitigation within 24-72 hours for critical internet-facing vulnerabilities, 7-15 days for high-severity issues, and 30-60 days for medium-severity issues. Require faster escalation for active exploitation and priority treatment of vulnerabilities in CISA’s Known Exploited Vulnerabilities Catalog. Track each material finding to an owner, deadline, deployed fix, and validation scan or retest. Exceptions require an approving authority, compensating controls, and an expiration date, not a “closed” ticket.[35]
Review the vulnerability disclosure policy and reporting channel. Check researcher safe-harbor terms, acknowledgment targets, and how the vendor tracks reports involving dependencies or subprocessors. A public bug bounty does not replace a working response process.[31] Weak disclosure practices also point to weak recovery and remediation.
After remediation, verify that recovery works under failure conditions. Request the latest backup-restoration, failover, and incident-recovery test dates, then compare the results with the contracted RTO and RPO. Tests should cover the application, APIs, identity systems, encryption keys, audit logs, and required dependencies. Require security validation before restored systems return to production, and ask for unresolved corrective actions and their owners.[33]
8. What Does the Contract Require During Service and Exit?
Turn every accepted control into a signed obligation after diligence. Review the MSA, DPA, security exhibit, SLA, support policy, and order form. Signed terms govern conflicts. Map those terms to your acceptance criteria and regulatory duties, and include audit rights and compliance-assistance duties in the signed contract.
Define data ownership, permitted use, confidentiality, and which obligations survive termination. Prohibit selling customer data or using it to train AI models without specific written permission. Cover prompts, logs, metadata, uploaded files, and derived data. Require downstream providers to accept the same confidentiality, security, privacy, breach, retention, and deletion terms. Include advance notice of provider changes, objection rights, and vendor liability for subcontractor failures.[40][41]
Make service commitments enforceable. Require incident notification within 24 or 48 hours of awareness of an incident affecting your data, cooperation with investigations, and evidence preservation. Specify uptime commitments, service credits, and remedies for repeated failures. Check whether credits are the exclusive remedy. Compare liability caps and indemnities against potential losses, and verify cyber liability and technology errors-and-omissions coverage. Link these commitments to the export and deletion terms below.
Require portable exports at exit. The contract should cover records, configurations, user records, attachments, audit logs, workflow history, and relevant metadata in machine-readable formats such as CSV or JSON. Set delivery deadlines, disclose fees, specify transition assistance, and define a read-only transition window.
Set deletion deadlines and retain proof. Require a production-data deletion deadline, a maximum backup-retention period, and a deletion certificate covering systems, subprocessors, exceptions, and legally retained data. If immutable backups cannot be deleted immediately, require their isolation and deletion on a fixed cycle. Document access revocation and keep export, deletion, and account-closure evidence in your exit file.[38][39]
Compare Requirements, Evidence, and Contract Terms
Compare each requirement against evidence and contract language in 1 matrix. Once the vendor answers Questions 1–8, use those answers and supporting documents to identify what is covered, what is binding, and what remains unresolved.
Buyer requirement Supporting document or report Contractual provision Open gap Assurance scope: Purchased self-service platform is covered SOC 2 Type II report Maintain comparable controls and provide annual reports New automated evidence-export feature is absent from the system description Breach notification: Notice within 24 hours of discovery Incident-response policy: notice after confirmation Notify within 24 hours, preserve evidence, and provide updates Discovery is undefined; suspected incidents may not trigger notice U.S. data residency: Storage, processing, backups, and support access stay in the United States Data-flow diagram: two U.S. production regions Require U.S.-only handling and consent for location changes Backup locations and overseas support access are unverified Subprocessor changes: Advance notice and objection rights Subprocessor register Give 30 days’ notice and a remedy if objections remain unresolved Emergency appointments bypass notice; termination rights are unclear Exit deletion: Data return and deletion Production-database deletion procedure Return data before deletion and certify deletion within 60 days Logs, backup schedules, and subprocessor copies are not addressed
For each artifact, record its date, scope, reviewer, exceptions, and remediation status. Review complementary user entity controls (CUECs) to identify the controls your team must provide. Check whether the audit includes subprocessor controls or excludes them through carve-outs.
Track each item as documented, binding, or unresolved. Assign an owner and deadline to every gap, and resolve it before signing. Request the missing artifact or contract clause - not another questionnaire answer.
Conclusion: Resolve Gaps Before Signing
Turn the completed comparison matrix into a decision record for all 8 questions. For each answer, document the supporting evidence, contract commitment, owner, next review date, and unresolved risk. Name the approver and residual-risk owner.[42][43]
Before signing, negotiate measurable duties: triggers, deadlines, scope, remedies, and vulnerability notification and remediation. Escalate gaps that affect legal compliance, sensitive data, or business continuity. Any accepted gap must have mitigation, a deadline, and written risk acceptance.[44][46]
Use the record for governance, not just sign-off. Review critical services annually and reopen the record after material vendor changes or a security incident.[43][45]
