Before a paid pilot, ask an African software partner for six documents: the ISO/IEC 27001 certificate with its scope and Statement of Applicability, a description of how it builds software securely, a recent penetration-test summary, a component list for the product, a subcontractor list, and two references. Each one answers a narrow question, none of them proves the pilot will go well, and a small firm may legitimately have only some of them.
This guide is general information for buyers, not legal or compliance advice. Where it describes a rule, the rule belongs to the authority named.
Key takeaways
- A certificate proves little until you read its scope line: the product you are buying has to sit inside it.
- Frameworks such as NIST's SSDF and OWASP SAMM describe practices; no one certifies a firm "SSDF compliant", so ask for evidence of the practice.
- A pen-test summary is a snapshot. Ask for the date, scope and retest status, not the headline rating.
- For a pilot, a firm that says "we do not have that yet, here is what we do instead" is giving you more information than one that sends a logo.
What each artifact proves
The table is ordered by how much it costs a vendor to produce, cheapest first.
| Artifact | What it can show | What it leaves open | |---|---|---| | References (two, one similar in size) | Delivery under real conditions | Whether the same team would deliver for you | | Subcontractor and hosting list | Who touches your data and code | How those parties are controlled day to day | | Component list (SBOM) | What third-party code is inside the product | Whether those components are exploitable in your use | | Pen-test summary | State of one system on one date | Everything outside the tested scope | | Secure-development description | Practices the team says it follows | Whether the practices run on every release | | ISO/IEC 27001 certificate | A management system was audited | Whether your product is inside the audited scope | | SOC 2 report | Controls examined by a CPA firm | Which of the criteria were in scope, and over what period |
The certificate is a scope statement
ISO/IEC 27001 is a standard for an information security management system. Certificates come from independent certification bodies, which national accreditation bodies assess against ISO/IEC 17021-1; ask who issued yours and whether that body is accredited. The detail that decides whether a certificate matters to you is the scope sentence printed on it.
Italy's accreditation body ACCREDIA sets a useful example. In a December 2024 technical circular for the bodies it accredits, it says the certification scope must explicitly reference the Statement of Applicability, the document listing which security controls the organisation applies and why, and its update status (ACCREDIA, Technical Circular DC 39/2024). That is one national body's rule for its own certifiers, so do not assume every certificate carries the same wording. It does tell you what a well-formed scope looks like: named services, named reference to the Statement of Applicability, a date.
So read three things. Does the scope name the service you will use, such as "development and maintenance of applications" or only "office administration"? Which sites are inside it? Is the Statement of Applicability dated, and will the vendor show it under an NDA?
A firm in Lagos, Nairobi or Cape Town that holds a certificate for its head office but builds your product in a separate team has certified something real and still has not certified your work.
Secure development: ask for the practice, not the badge
NIST's Secure Software Development Framework, published as SP 800-218 in February 2022, groups practices into four areas: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities (NIST SSDF). NIST describes the practices as outcome-based and meant to be tailored, not applied as a checklist. NIST also says the framework gives purchasers a common vocabulary for talking to suppliers.
No body certifies a firm against it. What you can ask is concrete: how is code reviewed before merge, where are dependencies checked, who can push to production, and how does a reported vulnerability reach a developer?
OWASP SAMM is a different tool. It is a self-assessment model with five business functions, fifteen security practices and three maturity levels per practice (OWASP SAMM). A completed SAMM scorecard from a ten-person firm is a self-report, but a dated one with a roadmap shows the team has looked at itself. CISA's Secure by Design guidance, revised in October 2023, names ownership of customer security outcomes and transparency as principles worth asking a vendor to demonstrate (CISA).
Penetration tests and component lists
The UK's National Cyber Security Centre is blunt about what a pen test cannot do. It shows whether a system was free of known issues at the time of testing, tests are often a year or more apart, and results depend heavily on tester skill (NCSC). Ask for the test date, the scope document, the severity scale, and whether the high findings were fixed and retested. Do not ask for the full report from a small firm on day one; a summary signed by the tester is usually the realistic request.
A software bill of materials, in CISA's phrase, is "a list of ingredients that make up software components" (CISA). Its companion, a VEX document, states whether a product is actually affected by a known vulnerability. ENISA's October 2026 advisory on SBOMs is explicitly non-mandatory guidance, not a reading of EU law. One line in it is worth borrowing: organisations should document known gaps in SBOM coverage, such as dependencies that cannot be identified. A vendor that lists its own gaps has probably built the list for real.
SOC 2, and why it is rarer than you expect
SOC 2 reports are produced by CPA firms under AICPA standards (AICPA & CIMA). The report examines controls against criteria for security, availability, processing integrity, confidentiality or privacy, and a vendor chooses which apply. So "we have SOC 2" is not an answer. Ask which criteria, which system, and which period.
Our reading: for a pilot with a firm under roughly fifty people, a missing SOC 2 report should not end the conversation, because the audit costs time and money that a sub-scale vendor may reasonably spend elsewhere. A missing description of what the firm does instead should.
Data protection registers
If personal data will flow, check the regulator's own list. Kenya's Office of the Data Protection Commissioner publishes a register of data handlers showing name, controller or processor type, registration number and status, with tabs for active, expired and deregistered entries (ODPC Kenya). Nigeria's regulator publishes a list of data controllers and processors of major importance, which it says is updated as approvals are made (NDPC). Registration shows a regulatory step was taken. It does not show the vendor's processing is lawful, and the ODPC page itself states nothing about who must register, so confirm the obligation with the regulator or counsel.
A worked example
Take a hypothetical case: a Dutch scale-up wants a 12-week pilot of a mobile-app rebuild with a 30-person studio in Accra. The studio has no ISO certificate and no SOC 2. A reasonable pack, asked for in one email, is a two-page description of its review and release process, a pen-test summary from the last twelve months for its own flagship app, an SBOM for one repository it chooses, the list of cloud and tooling subprocessors, and two client references. If the studio then delivers three of five with honest gaps, the buyer can price the remaining risk into the pilot: a smaller data scope, test data only, a retest clause.
That is a decision the buyer could not make from a certificate alone.
Buyer guidance
- Send the list once, early, with a reason for each item. Say that missing items are not disqualifying and that you want to know what exists.
- Put the real constraint first: if the pilot touches personal data of EU residents, say so, because that changes which items matter most.
- Match the ask to the size: for a 10-person firm, a process description and references; for a 100-person firm, add a certificate or report.
- Require subprocessors to be approved by you and obligations to flow down to them. ENISA's healthcare procurement guidance recommends this approval and flow-down, and also that the contract define permitted and prohibited uses of AI by suppliers.
- Agree an exit plan in the pilot contract: code hand-over, data return and deletion, and who owns what is built. Source-code escrow and IP assignment are commercial terms to negotiate with your lawyers; no standard here certifies them.
- If you will sell the resulting software as a product in the EU, read the Cyber Resilience Act page: reporting duties for actively exploited vulnerabilities apply from 11 September 2026, and the main obligations from 11 December 2027 (European Commission). Who counts as manufacturer for your arrangement is a question for counsel.
- To build the shortlist before you ask for any of this, the partner finder and the directory filter by category and country, and the countries index shows where profiles exist.
The strongest counterargument
A fair objection: paperwork requests favour firms that can afford compliance staff, and in Africa that tilts the field toward larger, often foreign-owned vendors. That is a real cost. The answer is to ask for evidence of practice at the level the firm can produce, and to let the pilot itself generate the rest: access reviews, a test environment, a short security call with the lead engineer. Documents reduce uncertainty; they never replace watching a team ship.
Frequently asked questions
Is ISO/IEC 27001 certification required to work with a European buyer? No law in the sources above requires it for a pilot. It is a common buyer preference, so read the scope on the certificate rather than treating its existence as an answer.
Can a startup be "SSDF compliant"? NIST describes the SSDF as practices to be tailored, and no certification body is attached to it. A startup can show it follows SSDF-style practices by providing review, dependency and vulnerability-handling evidence.
How old can a pen-test summary be? NCSC notes tests are often a year or more apart, so a summary older than twelve months should come with a note on what changed since. Ask also for retest evidence on the high findings.
Do I need an SBOM from a small vendor? Not necessarily for a pilot. If you plan to ship the code inside a product you sell in the EU, ask early, because the Cyber Resilience Act's reporting duties have applied since 11 September 2026 and most other obligations apply from 11 December 2027.
Sources
- ACCREDIA, Technical Circular DC 39/2024, Italian national accreditation body
- NIST Secure Software Development Framework
- NIST SP 800-218, SSDF Version 1.1
- OWASP SAMM
- CISA, Software Bill of Materials
- ENISA Technical Advisory for Software Bill of Materials, October 2026
- ENISA, Procurement guidelines for hospitals and healthcare providers
- UK NCSC, Penetration testing
- AICPA & CIMA, SOC suite of services
- CISA, Secure by Design
- European Commission, Cyber Resilience Act
- Kenya ODPC, Register of Data Handlers
- Nigeria Data Protection Commission
- NIST SP 800-218 final publication page