How to Evaluate Software Security for a Small Business

Software security cannot be established by a lock symbol on a supplier's website. A small business needs to know what information an application will hold, who can reach it, how the provider develops and maintains the service, and how the business will recover when something fails. That is particularly important when a property firm is choosing a CRM, document store, appointment service or outsourced customer-support platform. The decision involves both the supplier's security practices and the buyer's own configuration. Neither side can transfer every responsibility to the other.

In January 2026 the UK government updated its voluntary Software Security Code of Practice. The Code describes expectations for software vendors; it is not a compulsory accreditation or proof that an individual product has been independently certified. The ICO's UK GDPR guidance covers a different question: what an organisation must consider when using a processor to handle personal data. Use these original sources as two complementary tests, not as interchangeable seals of approval.

Classify the information and operational dependency

Begin by listing the data and actions the proposed application would control. Public marketing copy, staff calendars, tenant contact details and confidential identity records carry different consequences if they are disclosed, changed or unavailable. Mark which information is personal, financially sensitive or subject to restrictions, and identify the departments that legitimately need it. This is more useful than demanding identical security questionnaires for a disposable idea board and a live payment or property-management system.

Record an impact scenario for the actual process. If the supplier stops responding for a working day, can staff still reach customers and confirm appointments? If an employee accesses the wrong folder, whose information might be exposed? If a business account is taken over, could an attacker redirect invoices? A concise data-flow diagram and an accountable owner provide the foundation for deciding which assurances, permissions and recovery tests are proportionate.

Examine the supplier's software development and incident practices

The UK Software Security Code of Practice addresses secure design and development, management of software dependencies, deployment and maintenance, and communication with customers. Ask the supplier for its current security documentation, the scope of any assessment and how vulnerabilities are reported and fixed. A public statement that the company values security is not equivalent to a written incident process or evidence that its software receives supported updates. When a vendor supplies a certificate, check the named organisation, covered services, assessment period and exclusions.

For a small purchase, the evidence might be a current security page and reasonable answers to a focused questionnaire. A business-critical application merits closer review of patching, vulnerability disclosure, subcontractors and recovery commitments. Do not infer that a supplier conforms to the voluntary Code merely because it quotes it. Record unanswered questions, evaluate their impact and decide whether the product can be used within restricted boundaries pending further assurance.

Test identity, administrator recovery and least-privilege access

Create a trial administrator and two ordinary roles. Verify whether the product supports appropriate multifactor authentication, individual accounts and permissions that separate viewing from editing or financial approval. An agent may need to see a buyer's appointment without changing payout details or reading confidential records. A contractor might require access to one project for a limited period. Check the real behaviour with test accounts instead of relying only on a settings screenshot.

Then test a departure and a lost administrator device. Can an authorised colleague revoke access, terminate active sessions and recover administration through a documented company-controlled route? Are shared accounts unavoidable under the chosen pricing tier? Do former staff retain access through integrations even after their main account is closed? A system with excellent encryption but uncontrolled identities may still be an unsuitable operational choice.

Follow personal information into processors and integrations

Map the flow from website forms and email into the purchased tool, then into connected calendars, analytics, AI services or accounting software. Some integrations request broad scopes by default. Ask what each connection can read and write, who grants its permission, and how access can be revoked. Separate data necessary to deliver the service from data collected simply because an import button makes it easy.

Where the organisation is a controller using a processor, ICO guidance states that a written contract or another legal act is required and describes mandatory provisions, including documented instructions, confidentiality, security, subprocessors and end-of-contract arrangements. The specific roles depend on actual processing; a supplier's standard terms must be assessed, not simply accepted as proof of compliance. Keep a register of critical integrations so an employee's departure or a supplier change does not leave an unknown connection active.

Investigate backups, retention, exports and service failure

Ask what the supplier backs up, what the customer can restore, the available recovery history and how deleted records are handled. Do not assume a cloud service guarantees that every previous version is recoverable forever. Test a realistic example using non-sensitive records: delete a document or alter a field, then follow the supported recovery procedure. Record whether the result preserves attachments and meaningful links to other objects.

Export is a separate question. A CSV of customer names may be available whilst the history of approvals, consent and related files cannot be reconstructed. Ask what happens after cancellation and whether the provider offers a documented data-return and deletion process. Consider business continuity: staff may need a restricted offline contact route or a fallback booking procedure during an outage. Recovery should be designed around the service delivered to people, not only a supplier uptime percentage.

Read the limits of certifications, reports and security badges

Security certifications and penetration-test summaries can be useful, but only within their scope. A certificate may cover an organisation's management system rather than all the technical behaviour of a particular product. A penetration test assesses selected components at a particular time, not every future version. Ask whether identified issues were resolved and whether the buyer can obtain sufficiently meaningful assurance without requesting confidential vulnerability details.

Beware of false equivalence between evidence types. A policy describing how incidents should be handled is not a log demonstrating how a real event was resolved. Conversely, a small supplier without a familiar badge is not automatically insecure. The relevant question is whether the available evidence, direct tests and contractual controls are proportionate to the information and consequences involved. Record the basis for accepting residual risk rather than inventing an overall security score.

Pilot real failures and decide who owns the exceptions

Use the trial to test permission errors, an integration outage, a duplicate event, an account lockout and a request to retrieve data. Observe what users see and whether administrators can identify the cause. Check that a failed transaction cannot be described as successful simply because a notification was sent. In a property business, a booking status and a seller instruction may live in different systems; the security design must not let a broad automation account alter both without suitable controls.

Keep a short exception register with an owner, severity, required evidence and next action. A missed recovery test may block procurement for a critical system; a minor cosmetic admin issue may be acceptable. Require staff to report suspicious behaviour and maintain a genuine supplier support contact. Security is a continuing operating responsibility, so give someone the authority and time to review access and provider notices after purchase.

Make a proportionate procurement and renewal decision

Compare the actual business value with implementation work, permissions, supplier responsiveness, audit evidence, recovery and the cost of managing risk. A less expensive product is not a saving if it exposes the company to foreseeable interruptions or forces employees to share administrator logins. An elaborate enterprise package is not automatically necessary for a small, low-risk process either. Choose the level of assurance that fits the real data, users and consequences.

At renewal, review newly enabled integrations, changes in stored information, former employees' access, supplier notices and the most recent restoration test. The correct outcome of a security evaluation is not 'certified safe'. It is a documented decision explaining what the product does, the evidence for important controls, the risks still open and the person responsible for managing them.

Official sources: UK Government Software Security Code of Practice, voluntary supplier guidance updated 15 January 2026, UK context; ICO guidance on controller–processor contracts, UK GDPR scope, under review following later legislation; NCSC supply-chain guidance, broader vendor risk. These sources do not certify a named product.