Software vendor due diligence for security and ownership

Quick answer

Do not buy a software promise. Buy verifiable responsibilities. Before signing, name the owner of every important account, data flow, integration, operational decision, and exit activity. Ask for a current data map, access model, incident procedure, recovery evidence, API catalogue, and handover plan. This is a procurement guide, not legal advice or a claim that one control makes a system compliant.

Data map and GDPR questions

Build one data map with the source, purpose, data type, recipient, storage location, access roles, retention rule, and export or deletion route for every flow. Separate customer records from logs, analytics, backups, and test data. Then ask who approves a change of purpose and who responds when a data subject needs information.

GDPR distinguishes controllers and processors. Article 28 says that processing on a controller's behalf should be governed by a contract covering the subject matter, duration, nature, purpose, types of personal data, categories of data subjects, and duties and rights. Confirm your particular roles with counsel and your privacy lead. Ask who determines purpose and means, which sub-processors are used, and how their changes are notified. Rise.sk privacy information describes our public approach. It cannot replace an analysis of your contract.

Access control and auditability

Request an account and environment register. Include cloud administrators, production databases, repositories, CI, domains, email, analytics, advertising accounts, and support tools. Check whether every person has an individual account, whether sensitive roles use multi-factor authentication, and how access is revoked when a person leaves or changes responsibility.

An audit trail should answer who performed a sensitive action, when, from which account, and with what result. Ask for evidence around administrator sign-ins, permission changes, exports, configuration changes, and production interventions. OWASP ASVS can be used as a procurement baseline for checking technical application controls. It is not a product badge. Rise.sk security information explains our public security principles.

Secure development, dependencies, and recovery

Ask how the vendor protects source code, reviews changes, and handles vulnerable dependencies. Request the process for code review, secret scanning, library updates, severity assessment, and an urgent fix outside the usual release cycle. NIST SP 800-218 describes practices for integrating secure development into a software lifecycle. CISA Secure by Design argues that the customer should not carry the security burden alone.

Backups need more than a yes or no. Ask where they reside, how they are protected, how long they are retained, who can restore them, and when restoration was tested. Agree a data and service recovery objective, incident contact, first-status expectation, and evidence-preservation step. ENISA Threat Landscape 2024 is useful context for threat and resilience discussions. A written plan is not proof of a practiced recovery.

API ownership and integration failure modes

Every API creates an operational and ownership obligation. Record the API owner, purpose, contract basis, authentication, rate limits, version, costs, personal data, and failure procedure. You should know what happens after an expired token, slow response, duplicate message, incompatible change, or third-party outage. Name the person who can contact the provider and alter the billing plan.

Prepare a manual continuation route for each critical workflow. An accounting connection can fail, but invoices and approvals must not disappear into an unseen queue. Compare the proposed delivery, decision, and acceptance steps with the Rise.sk process.

Ownership, licences, and support

The contract and annexes should separately identify source code, repositories, domains, cloud accounts, databases, DNS, email, analytics, advertising accounts, design files, documentation, passwords, and recovery codes. For each item, record the entitlement, administrator, billing contact, storage location, and handover action. A customer asset should not depend on a vendor employee's personal email address.

Check licences for proprietary code, open-source packages, templates, fonts, photographs, APIs, and paid services. Ask about licence limits, renewals, minimum terms, exports, and non-payment consequences. An SLA should distinguish support hours, priority, response target, recovery target, maintenance window, and exclusions. A target is not a guarantee unless scope and measurement are specified.

Exit plan, evidence, and internal consensus

Validate the exit plan before the project begins. It should cover a documented data export, repository history, account and integration inventory, infrastructure documentation, deployment instructions, secrets transferred through a safe channel, and transition assistance. Try a small export and a customer login to an owned account. That is more informative than a handover promise.

An evidence pack can contain the data map, access register, latest recovery test, dependency inventory, security findings and remediation status, sub-processor list, account schedule, API catalogue, SLA, and acceptance criteria. A contract annex should cover system scope, ownership, data roles, security measures, incident notification, backups, integrations, licences, support, export, and handover. Counsel can then assess the wording for your situation.

Bring together business ownership, IT, finance, marketing, and privacy responsibility. Every open point needs a decision, owner, and date. Rise.sk services can support a technical assessment, and more decision material is available in the blog. Read the terms before engaging us.

Sources

• GDPR on EUR-Lex
• OWASP ASVS
• NIST SP 800-218 SSDF
• CISA Secure by Design
• ENISA Threat Landscape 2024