Customer security and privacy questionnaire answer bank (grouped by CAIQ / CCM domains)

Structure (11 sections)

1. 1. Governing the bank: ownership, versioning, validity and approval

   Fix the rules first, or the bank will degrade into several contradictory documents within a quarter. Record for each answer: the owning function (security, legal, infrastructure, HR), the approver, the last review date and a validity period (six months or less is a sensible cap), and the classification that determines whether it may be sent externally as-is. Define three answer states: usable verbatim, requires tailoring per customer, and requires case-by-case legal approval. Sales may draw only on the first during proposals; anything committing to timescales, indemnities or audit rights goes through the third. Keep the bank consistent with the security exhibit of your contract templates — answering "supported" in a questionnaire while the contract says "no commitment" gets bounced at legal review.

   Evidence to attach

   • · Answer bank register (question, answer, owner, approver, review date, validity, state, classification)
   • · Cross-check between bank answers and the security exhibit clauses of the contract
   • · Expiry reminder mechanism and review records
   • · Approval workflow for external release

   Common pitfalls

   • · The bank is maintained by presales while security is unaware, so answers drift from the actual controls
   • · No validity mechanism, so an architecture description written two years ago is still in use
   • · Sales forwarding the internal bank verbatim to a customer, leaking internal system names and topology detail

2. 2. Service scope statement and shared responsibility model

   Every questionnaire response should open with a fixed scope statement: which product or service is covered, which deployment models (multi-tenant SaaS, single tenant, on-premises, edge device), which regions and cloud providers host it, and which controls sit with you versus the customer. Express the shared responsibility model as a table rather than a paragraph: mark each CCM domain as your responsibility, the customer’s, or shared, and for shared items state the hand-off point. For a Chinese vendor selling to Western customers, also mark which controls are performed by PRC-based teams and which by offshore entities — the customer’s third-party risk team uses exactly that to assess data exposure and cross-border risk.

   Evidence to attach

   • · List of products and deployment models with the control scope for each
   • · Shared responsibility matrix by CCM domain, with hand-off points for shared items
   • · List of hosting regions, cloud providers and sub-processors
   • · Control ownership table annotated by performing entity (onshore / offshore)

   Common pitfalls

   • · One answer set covering every product line, until the customer discovers that on-premises and SaaS controls differ entirely
   • · A shared responsibility statement that says only "per industry practice", giving the customer nothing to assess against
   • · Not disclosing sub-processors and hosting regions until after signature, triggering a re-review

3. 3. Governance, risk and compliance (GRC) and audit and assurance (A&A)

   This group asks whether you run a system, not whether you have a single technical control. Answer skeleton: the approval level and review cycle of the security policy; the security organisation and responsibilities (including whether there is a dedicated security lead and to whom they report); the frequency, method and last execution date of risk assessment; the compliance obligation register and how it is tracked; certifications and reports held (ISO/IEC 27001 certificate number and scope, SOC 2 report type and coverage period, CSA STAR registry listing URL); and the frequency and latest conclusions of internal audit and management review. Where you hold no certificate, do not hedge — writing "not yet obtained, initiation planned for X, currently mitigated by control Y" passes review far more often than "compliant with international standards".

   Evidence to attach

   • · Security policy text, approval record and review cycle
   • · Security organisation chart and role descriptions including reporting lines
   • · Latest risk assessment report and risk treatment plan
   • · Certificate scans (number, scope, validity) and the SOC 2 report with any bridge letter
   • · Internal audit plan, audit reports and management review minutes
   • · Compliance obligation register

   Common pitfalls

   • · Producing an ISO/IEC 27001 certificate whose scope covers one office rather than the service being sold
   • · A SOC 2 report whose coverage period has lapsed with no bridge letter available
   • · Writing "certified to ISO/IEC 27001" when the truth is "aligned with ISO/IEC 27001", then being unable to produce a certificate
   • · A risk assessment report dated two years ago with no record of annual execution

4. 4. Identity and access management (IAM), cryptography and key management (CEK)

   Answer at the level of mechanism, not principle. Identity and access: joiner-mover-leaver processes and their time limits, how least privilege and separation of duties are implemented, privileged account management (bastion hosts, just-in-time elevation, session recording), the coverage of multi-factor authentication (does it cover the whole management plane and VPN), the frequency and last execution of access reviews, and the single sign-on and directory synchronisation protocols offered to customers. Cryptography: algorithms and key lengths in transit and at rest, key generation and custody (KMS or HSM), rotation cycles, whether bring-your-own-key is supported, and the separation of production keys from development. One question Chinese vendors are always asked: how operations staff accessing overseas production from within the PRC are authenticated and audited — answer it directly rather than deflecting.

   Evidence to attach

   • · Joiner-mover-leaver and access change process documents with recent (redacted) ticket samples
   • · Privileged access management configuration screenshots and session audit log samples
   • · Multi-factor authentication coverage list
   • · Access review records (date, scope, findings and remediation)
   • · Encryption and key management policy, KMS/HSM configuration note and rotation records
   • · Design note on authentication and auditing for cross-border operations access

   Common pitfalls

   • · Answering "industry-standard encryption" without naming algorithms or key lengths
   • · Claiming universal MFA while the operations jump host uses a shared account
   • · An access review policy with no evidence that it was ever executed
   • · Deflecting the cross-border operations access question, from which the customer infers an undisclosed data exposure

5. 5. Data security and privacy (DSP): classification, retention, deletion and cross-border transfer

   This is the group where AI vendors get pressed hardest. Prepare answers on: the data classification scheme and the default class assigned to customer data; how customer data is separated physically and logically (for multi-tenancy, describe the implementation — the phrase "logical separation" is not enough); retention periods and how expiry deletion is triggered and verified; response times when a customer requests deletion and how residual copies in backups are handled; the route, legal mechanism and completed assessments for cross-border transfers (for a Chinese vendor, the status of the personal information protection impact assessment and of standard contract filing or security assessment should be producible); and the decisive one — whether customer data is used for model training. That last answer must state an unambiguous default and the configurable options; hedging on it is treated in legal review as the highest-risk item.

   Evidence to attach

   • · Data classification scheme and the default class for customer data
   • · Technical note on multi-tenant separation (layer of isolation and how it is verified)
   • · Retention and deletion policy, expiry deletion execution records and backup retention note
   • · Data flow diagram covering onshore and offshore links, sub-processors and storage locations
   • · Personal information protection impact assessment, transfer mechanism documents and filing status
   • · Product default and contractual clause on whether customer data is used for model training, plus configurable options

   Common pitfalls

   • · A "we do not train on customer data" claim that lives on the marketing page but not in the contract or the product default
   • · A deletion commitment that covers the production database but says nothing about backups, leaving the retention question unanswered
   • · A data flow diagram that does not match the real architecture (omitting onshore log analytics or support systems, for example)
   • · Answering the transfer question with "a standard contract has been signed" but producing neither the filing receipt nor the impact assessment

6. 6. Application and interface security (AIS), change control (CCC), threat and vulnerability management (TVM)

   Secure development: security review at requirements and design stage, the tooling and cadence of code review and static/dynamic scanning, dependency and open-source component management (do you produce a software bill of materials), and how secrets are kept out of the repository. Change control: change classification, approval path, rollback plan, and four-eyes review and logging for production changes. Vulnerability management: scan frequency, remediation deadlines by severity (state days, not "promptly"), penetration testing frequency and who performs it (internal or third party, and whether a summary report can be shared), and the vulnerability disclosure and bounty channel. For products sold into the EU, the Cyber Resilience Act places direct requirements on vulnerability handling and the SBOM for products with digital elements; keep these answers aligned with the product-side compliance work.

   Evidence to attach

   • · Secure development process documents and sample design review records
   • · SAST/DAST/SCA configuration and a summary of the most recent scan results
   • · Sample software bill of materials and how it is generated
   • · Change management process and recent production change tickets
   • · Vulnerability remediation SLA policy and actual attainment statistics
   • · Third-party penetration test summary and the remediation closure record

   Common pitfalls

   • · Remediation deadlines expressed as "as soon as possible" or "case by case", which buyers score at worst case
   • · Claiming annual penetration testing but being unable to produce the report, or producing one whose scope does not match the service sold
   • · No SBOM available when the customer contract already obliges you to provide one
   • · Scanners deployed but high-severity findings left open for months, discovered when attainment statistics are sampled

7. 7. Infrastructure and virtualization (IVS), datacenter security (DCS), logging and monitoring (LOG), universal endpoint management (UEM)

   Infrastructure: network segmentation and production/non-production separation, hardening baselines and how often conformance is checked, security configuration of container and orchestration platforms, image provenance and signing. Datacenter: physical access control, surveillance and environmental controls for owned facilities; where public cloud or colocation is used, cite the provider’s compliance evidence and state the part you own under shared responsibility. Logging and monitoring: collection coverage (does it include management-plane actions and data access), retention period, tamper protection, alerting and staffing (is it 24/7), and whether customers can obtain audit logs relating to their own data. Endpoint: encryption, patching, anti-malware and loss handling for corporate devices, and whether engineering endpoints may touch production data, plus controls on source code leaving the environment.

   Evidence to attach

   • · Network topology and segmentation note (production / non-production / management plane)
   • · Hardening baselines and conformance check reports
   • · Cloud and colocation provider compliance evidence (SOC 2, ISO certificates) and the shared responsibility note
   • · Log collection scope, retention policy and tamper-protection configuration
   • · On-call and alert response arrangements including rotation and escalation
   • · Endpoint management platform configuration and compliance rate statistics

   Common pitfalls

   • · Log retention shorter than the forensic period required by the customer contract
   • · Developers with direct access to production data without approval or audit
   • · Passing off the cloud provider’s compliance evidence as your own controls without stating the shared responsibility boundary
   • · Answering "24/7 monitoring" when it is in fact a rotating phone duty with no stated response time

8. 8. Business continuity and resilience (BCR), security incident management and forensics (SEF)

   Continuity: when the business impact analysis was performed and what it concluded, recovery time and recovery point objectives (numeric, by service tier), backup strategy and off-site or cross-region arrangements, the date and outcome of the last recovery exercise, and exit and data retrieval arrangements (how customers get their data back on termination, in what format and by when). Incident management: severity classification, detection-to-response timescales, notification channels and deadlines (separating contractual customer notification from statutory notification), forensic capability and evidence preservation, and post-incident review with remediation tracking. Chinese vendors should use this section to set out the multiple statutory notification duties clearly: personal data breach notification for the EU, network data security incident reporting to PRC regulators, and contractual customer notification all run to different clocks, so the bank should carry one internal trigger table rather than leaving front-line staff to judge in the moment.

   Evidence to attach

   • · Business impact analysis report and the RTO/RPO definition table
   • · Backup strategy, off-site arrangements and the latest recovery exercise report
   • · Exit and data retrieval procedure (format, deadlines, verification)
   • · Incident severity classification and response flow
   • · Notification trigger table (statutory vs contractual, with deadlines and owners)
   • · Recent post-incident reviews and remediation closure records (redacted)

   Common pitfalls

   • · RTO/RPO figures that were never validated by an exercise, with no exercise report to produce
   • · Committing to a customer notification deadline shorter than your actual detection capability, guaranteeing breach
   • · Exit arrangements that say only "assist the customer in exporting data", with no format or deadline — a reliable contract sticking point
   • · Conflating statutory and customer notification, producing either a missed filing or over-disclosure

9. 9. Supply chain transparency and accountability (STA): sub-processors and subcontracting

   Provide the sub-processor and key supplier list (name, service, location, data types involved), the onboarding assessment method, the security and data protection clauses in those contracts, the change notification mechanism (how many days’ notice to customers, and whether they may object), and how downstream providers are monitored on an ongoing basis. EU customers focus on two things: whether the processor contract flows equivalent obligations down to sub-processors, and whether supply chain security measures cover direct suppliers. Financial-sector customers will also send the contractual elements required for ICT third-party service arrangements and ask for a clause-by-clause confirmation — the bank should carry a prepared comparison table marking which clauses are acceptable and which need negotiation.

   Evidence to attach

   • · Sub-processor and key supplier list with locations and data types
   • · Supplier security assessment records and onboarding criteria
   • · Template data protection and security addendum signed with sub-processors
   • · Sub-processor change notification mechanism and past notification records
   • · Comparison table against the contractual elements required by financial-sector customers (acceptable / negotiable / not acceptable)

   Common pitfalls

   • · A sub-processor list that omits foundation model and compute providers, which the customer finds during architecture questioning
   • · Promising that sub-processors carry equivalent obligations while unable to produce a signed addendum
   • · No change notification mechanism, so a silent sub-processor swap surfaces during the customer’s annual re-review

10. 10. AI-specific follow-ups: models, training data, outputs and human oversight

    Beyond the traditional security questionnaire, buyers increasingly attach an AI-specific one (such as CSA’s AI Controls Matrix and the companion AI-CAIQ). Pre-draft answers covering: the model inventory (in-house or third-party, with version and provider); the provenance and rights status of training and fine-tuning data; whether customer data enters training and how it is segregated; data retention and logging at inference; the method and frequency of model evaluation and red teaming; labelling and traceability of outputs; mitigations for hallucination and harmful output; human oversight and takeover mechanisms; and change management and customer notification for model updates. For EU sales also prepare: your role in the AI value chain (provider or deployer), whether the use case is high risk, and the instructions for use and technical information you can supply to deployers.

    Evidence to attach

    • · Model inventory (in-house or third party, version, provider, purpose)
    • · Training and fine-tuning data provenance list with rights status
    • · Summaries of model evaluation and red team testing
    • · How output labelling is implemented and how outputs are traced
    • · Product implementation note on human oversight and takeover
    • · Change management process for model updates and customer notification records
    • · Instructions for use and technical information pack for deployers

    Common pitfalls

    • · Answering "we do not retain inference data" while the logging system in fact keeps full request payloads
    • · Not disclosing the provider and version of the third-party foundation model, so the customer cannot complete its own supply chain assessment
    • · Vague training data rights status, from which customer legal concludes the IP risk is unacceptable
    • · Silent model updates that customers notice only when behaviour changes — the trust damage is harder to repair than the technical issue

11. 11. How to answer gaps, exceptions and compensating controls

    The most valuable part of the bank is usually not the "yes" answers but making the "no" acceptable. Use a four-part form: (1) state plainly that the control is not in place today; (2) describe the compensating controls and how far they reach; (3) give the remediation milestones with named owners; and (4) set out the contractual arrangement you can offer in the meantime (a tighter notification deadline, or a restriction on data types, until the control lands). Never use "partially compliant" or "in progress" — experienced reviewers read them as "no" and deduct extra for evasiveness. Also maintain a list of standing refusals: the questions you will not answer (detailed network topology, specific security product models, employee personal data), each with an agreed alternative (a demonstration under NDA, or the corresponding section of a third-party audit report).

    Evidence to attach

    • · Control gap register (gap, compensating control, plan, owner, deadline)
    • · Evidence that compensating controls were validated
    • · Standing refusal list with the agreed alternative for each
    • · Legal assessment of how each gap affects contractual commitments

    Common pitfalls

    • · Answering "yes" to pass review and being caught in the customer’s on-site audit after delivery — far worse than losing points up front
    • · Remediation plans that slip year after year, which customers spot by comparing line by line at renewal
    • · Refusing to answer without offering an alternative, which is recorded as non-cooperation