Security and compliance questionnaire for lending software vendors

• Send the full questionnaire to your shortlist before the security review call.
• Require written answers; reserve the call for the answers that need evidence on screen.
• Score each line Yes / Partial / No, and ask for the artefact behind every Yes: a report, a policy, a configuration screen.
• Treat a vendor that cannot answer a state-change or audit-trail question as having answered No.
• Cross-reference the highest-weighted findings against your vendor evaluation scorecard.

A state-change is any action that alters the book: a waiver, a reschedule, a write-off, a disbursal, a settlement. Throughout this questionnaire, “every state-change is audited” means the platform records who did it, what changed, and on what evidence.

1. In which countries and regions will borrower data be stored, processed, and backed up?
2. Can data residency be pinned to a single region per tenant, with no cross-border replication?
3. Where do logs, backups, analytics copies, and AI-feature data reside, separately from the primary database?
4. For cross-border or multi-entity lenders, can each entity run in its own residency boundary?
5. Does any support, monitoring, or model-inference path move borrower data outside the contracted region, even transiently?
6. How is residency enforced and evidenced: contractually, by configuration, or by deployment topology?

1. Is data encrypted in transit (TLS), and is mutual TLS (mTLS: both sides authenticate) available for service-to-service traffic?
2. Is data encrypted at rest at the database and backup level?
3. Is sensitive personal data (PII) encrypted at the field level, above whole-disk encryption?
4. How are encryption keys managed, rotated, and separated from the data they protect?
5. Can keys rotate without re-encrypting or losing access to historical records?
6. Who can access keys, and is every key-access event logged?

1. Is access role-based (RBAC), with permission groups rather than per-user grants?
2. Does authorisation respect an organisational hierarchy: branch, region, partner, tenant?
3. Is single sign-on supported through OIDC / OAuth2 against the lender’s identity provider?
4. Is maker-checker enforced on every state-changing action: product changes, waivers, reschedules, write-offs, settlements, disbursals?
5. Can the maker-checker policy vary by action type, amount band, and risk level?
6. Are privileged and break-glass accounts separately governed, time-boxed, and logged?
7. Can a single individual both make and approve the same change under any configuration?

1. Is every state-change captured with actor, action, timestamp, evidence, and before/after?
2. Is the audit trail append-only and tamper-evident: can a record be altered or deleted without trace?
3. Does the same audit model cover human actions, API actions, and any automated or AI actions?
4. Is the trail queryable and exportable for regulators and auditors without a vendor SOW?
5. How long is the audit trail retained, and is retention configurable to the lender’s policy?
6. Can the lender reconstruct the full history of a single loan account from the trail alone?

1. How does the platform support the RBI Digital Lending guidelines: KFS (Key Fact Statement), cooling-off period, and direct lender-to-borrower fund flow?
2. Can the system evidence that loan terms, charges, and APR were disclosed and recorded?
3. Does the platform support the data-localisation expectations applicable to regulated lenders?
4. Can regulatory returns and audit evidence be produced from the system of record, not from a reconstructed copy?
5. How does the vendor keep pace with regulatory change, and who carries the obligation to update?

1. Does the platform support data-principal rights: access, correction, and erasure requests?
2. Is consent captured, versioned, and auditable, with a record of purpose and withdrawal?
3. Can personal data be located across the system to satisfy a single subject request?
4. Are data-processing roles (controller / processor) defined contractually for this engagement?
5. How is personal data minimised, masked, or tokenised in non-production and analytics environments?

1. Can retention periods be set per data category and per regulatory obligation?
2. When an account or borrower reaches end-of-life, how is data deleted or anonymised, and proven?
3. Are backups and replicas covered by the same retention and deletion policy as primary data?
4. Does deletion preserve the audit and accounting record the regulator still requires?
5. Can the lender export its full dataset on exit, in a documented format, without penalty?

1. What are the committed RTO and RPO, and are they contractual?
2. How often are backups taken, and how often is restore actually tested end-to-end?
3. Is there a documented, rehearsed disaster-recovery plan, and when was it last exercised?
4. Is there geographic redundancy within the contracted residency boundary?
5. What is the committed availability target, and how is downtime measured and reported?

1. When was the last independent penetration test, and can a summary be shared under NDA?
2. Are findings tracked to closure, and can the closure status be evidenced?
3. Does the vendor hold or pursue SOC 2 Type II and/or ISO 27001, and what is the current status?
4. Is there a secure software-development lifecycle: code review, dependency scanning, secrets management?
5. Is there a published vulnerability-disclosure path and a defined remediation SLA by severity?

1. Is there a current, named list of sub-processors, including any model or AI providers?
2. Where does each sub-processor operate, and does any move data outside the residency boundary?
3. Are sub-processors contractually bound to equivalent security and data-protection terms?
4. Is the lender notified before a new sub-processor is added, with a right to object?
5. Does any sub-processor use the lender’s borrower data for its own purposes or model training?

1. What is the incident-notification commitment, in hours, for a confirmed data breach?
2. What does the incident-response process cover: detection, containment, forensics, comms?
3. Who owns regulator and data-principal notification, the lender or the vendor?
4. Are post-incident reviews shared with the lender, with root cause and corrective actions?

1. For any AI or agent feature: can it take a state-changing action on the book on its own, and if so, is that action gated by maker-checker and recorded in the same audit trail as a human action?
2. Is borrower data used to train shared or vendor-owned models, and can the lender opt out?
3. When the model is unavailable or low-confidence, what does the system do: fail safe, or proceed?
4. Can the lender see, for any AI-influenced decision, what data was used and what action resulted?

Sixty-plus questions across twelve categories. Score Yes / Partial / No, and ask for the artefact behind every Yes.

• Who should fill in this questionnaire?

  The CRO or compliance lead owns the regulatory questions (RBI, DPDP Act, retention); the InfoSec or security team owns encryption, access control, BCP/DR, and penetration testing. The vendor’s security and product teams answer; the buyer scores and asks for evidence.

• How is a security questionnaire different from an SOC 2 report?

  A SOC 2 report is an independent attestation of a vendor’s controls over a period. This questionnaire is the buyer’s own scope: it asks the questions specific to a regulated loan book in India, including RBI Digital Lending and DPDP Act readiness, that a generic SOC 2 will not spell out. Use both: ask for the SOC 2, and use this to test what it does not cover.

• Should we ask these questions of an LOS vendor too, or only a Loan Management System (LMS) vendor?

  Both. An LOS (Loan Origination System: the pre-disbursal application and underwriting platform) handles KYC data, bureau pulls, and decisioning, so residency, access control, audit, and AI governance matter just as much there as in the LMS that runs the book afterwards.

• What is the single most revealing question here?

  Whether every state-change is captured with actor, action, evidence, and before/after in a tamper-evident trail, and whether automated and AI actions ride the same trail. A platform that cannot answer this cleanly will struggle with every regulator conversation that follows.

• The vendor says its AI does not take state-changing actions. Is that enough?

  It is a reasonable answer if it is true and enforced. Ask how it is enforced, by architecture or by policy, and ask what is logged when the AI proposes an action a human then approves. The proposal, the data used, and the human approval should all be in the audit trail.

• What if a vendor declines to answer a question?

  Record it as a finding. A vendor that cannot speak to data residency, audit immutability, or sub-processors during evaluation will not become more transparent after signing. Deflection is information.