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 and every data flow. Name who owns each integration, who takes the operational decisions and who runs the exit.

Ask the vendor to produce, on paper:

• a current data map
• the access model
• the incident procedure
• recovery evidence
• the API catalogue
• the handover plan

This is a procurement guide. It is not legal advice, and no single control on that list makes the system compliant.

Data map and GDPR questions

Build one data map. For every flow it carries the source, purpose, data type, recipient, storage location, access roles, retention rule, export route, deletion route. Customer records, logs, analytics, backups and test data each get their own rows, because their retention periods differ, as do the people allowed anywhere near them. Then ask who approves a change of purpose and who picks up the phone when the data subject asks what you hold on them.

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, duties, 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 whatever the support desk runs on. Check whether every person has an individual account, whether sensitive roles use multi-factor authentication, and how access is revoked on the day somebody changes role rather than three months later. The same goes for the day they leave.

An audit trail should answer who performed a sensitive action, when, from which account, with what result, and it should still answer six months later, when the auditor asks. Ask for evidence around administrator sign-ins, permission changes, exports, configuration changes and anything done directly in production. 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. Then ask for the written process covering code review, secret scanning, library updates, severity assessment, and the urgent fix that has to ship outside the usual release cycle. NIST SP 800-218 describes practices for integrating secure development into a software lifecycle. CISA Secure by Design puts it more bluntly. 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 somebody last proved it by restoring something. Agree a data and service recovery objective. Agree who the incident contact is, when the first status arrives and what evidence gets preserved before anyone starts fixing. 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, failure procedure. You should know exactly what the application does after an expired token, a slow response, a duplicate message, an incompatible change from the provider, or a third-party outage. Name the person who can contact the provider. Name the person who can alter the billing plan.

Prepare a manual continuation route for each workflow the company cannot pause, even if that route is one spreadsheet, with one named person watching it for the week it takes. An accounting connection can fail. Invoices and approvals must not disappear into an unseen queue while it is down. 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 the recovery codes that go with them. Every one of them. For each item, record the entitlement, administrator, billing contact, where it is stored and what has to happen at handover. 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 every paid service in the stack. Ask about licence limits, renewals, minimum terms, exports, and what happens to your data on the day an invoice goes unpaid. An SLA should distinguish support hours, priority, response target, recovery target, the maintenance window and the list of things it does not cover. None of those targets is a guarantee. The guarantee lives in the scope and in the measurement written next to it.

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. Then try a small export and a customer login to an owned account. Nothing in a handover document ever fails. The first attempt to use it does.

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 the acceptance criteria the contract names. A contract annex should cover system scope, ownership, data roles, security measures, incident notification, backups, integrations, licences, support, export and handover, one clause each. Counsel can then assess the wording for your situation.

Bring together business ownership and IT with finance, marketing and the person answerable for privacy. Every open point needs a decision, an owner, and the date by which the decision has to exist. Rise.sk services can support a technical assessment, and more decision material sits in the blog for the parts of this you want to argue out internally first. 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