Software Bought in the Margins: Board Control of Departmental SaaS

Most UK mid-market boards have a procurement policy. Fewer have a reliable picture of the software bought outside it. A departmental manager signs up for a collaboration tool, a marketing team trials an analytics platform, or a finance function adopts an expense-add-on. The purchase is small enough to pass on a corporate card or expense claim, useful enough to be adopted quickly, and invisible enough to escape the board pack. The result is not necessarily reckless spending. It is an assurance gap: the organisation may be holding company or customer data in places the board cannot see, under terms nobody has reviewed.

The gap is created by convenience, not malice

Shadow SaaS rarely begins with an intent to bypass controls. It begins with a business need and a low-friction route to meet it. Procurement is designed for larger contracts, security review is designed for planned projects, and IT is designed for managed estates. A monthly subscription can sit beneath all three. By the time the tool appears in accounts payable, it may already hold customer records, employee data or commercially sensitive documents.

The board does not need to treat every departmental purchase as a failure of culture. It does need to recognise that distributed purchasing changes the risk profile. The organisation's data map is no longer defined only by systems that went through a project board. It is also defined by tools that arrived through a card statement.

Why this becomes a board issue

For a UK board, the concern is broader than duplicate subscriptions. Under UK GDPR, the organisation remains accountable for personal data wherever it is processed. Customer contracts may impose residency, security or audit obligations that a departmental tool cannot meet. A supplier's standard terms may permit subprocessors, overseas storage or broad use of data that the organisation would not have accepted through a formal review. When a contract renewal, subject access request, incident or exit arises, the organisation needs to know what data is held, where, by whom and under what terms.

A shadow SaaS estate undermines that position in three ways. It weakens the data inventory, because the board is relying on an incomplete list. It weakens contractual assurance, because nobody has checked the supplier's terms. And it weakens exit control, because tools adopted at the edge are rarely deprovisioned with the same discipline as central systems. The risk is not hypothetical; it is simply unmeasured until something goes wrong.

Start with spend visibility, not a blanket ban

A blanket prohibition is rarely workable in a business that values speed. It also drives purchases further underground. The more effective first step is to make the existing spend visible. Finance teams already hold much of the evidence: corporate card transactions, expense claims, accounts payable records and software line items buried in broader supplier invoices. A quarterly reconciliation of recurring SaaS-like payments can produce a working inventory without a major technology programme.

The board should ask for this as management information, not as a forensic exercise. The output should show the vendor, business owner, estimated annual spend, data types involved and whether the tool has been through any review. Names on statements do not always match product names, so finance and IT should reconcile aliases. The aim is a defensible list, not a perfect one.

Use risk-based approval thresholds

Approval thresholds should be tied to data sensitivity as well as spend. A low-cost tool that processes customer personal data deserves more scrutiny than a higher-cost tool that holds only public marketing material. A practical framework can define three routes: pre-approved tools that meet standard security requirements; tools requiring a short review because they touch internal or personal data; and tools requiring full procurement and security assessment because they are customer-facing, business-critical or involve special category data.

The threshold should be simple enough for departmental managers to use without a procurement specialist. It should also be visible in the places where purchases begin: the expense system, the corporate card policy and the intranet. The message is not that managers cannot buy software. It is that the route depends on what the software will hold.

Keep the security questionnaire genuinely light

A lightweight questionnaire is more likely to be completed than a full assurance pack. For lower-risk tools, ten questions may be enough: what data will be stored; where will it be held; who are the subprocessors; is access protected by single sign-on and multi-factor authentication; is data encrypted in transit and at rest; can data be exported; can it be deleted on exit; what is the incident notification commitment; is there a data processing agreement; and what certifications or independent assurances exist.

The board does not need to review every answer. It needs to know that a consistent gate exists and that exceptions are recorded. For tools that fail the light review, the decision should be explicit: remediate, restrict the data, or stop using the tool. Silence is not an approval.

Treat exit as part of the control

Shadow SaaS often persists because nobody owns the offboarding. A tool bought for a six-week project can remain active for years, holding data and generating invoices. The control set should therefore include renewal dates, named owners, data export arrangements and deletion confirmation. When a team changes supplier or a project ends, access should be removed through the identity provider where possible, and the supplier should confirm deletion in line with the contract.

This is unglamorous work, but it is where much of the assurance is won. A board that can show a current inventory, a risk-based approval route and evidence of exit checks is in a far stronger position than one that relies on a policy alone.

What the board should ask

Five questions can test the current position. First, can management show a list of SaaS tools bought outside procurement in the last twelve months? Second, which of those tools hold customer or employee personal data? Third, what review did they receive before use, and who approved any exceptions? Fourth, how are renewals, data exports and deletions managed when a tool is no longer needed? Fifth, what proportion of the estate is now visible, and how is that improving quarter by quarter?

The answers should be reported as a governance metric, not a one-off audit. The board's role is to set the appetite, require the map and challenge the exceptions. Clear-headed control does not mean stopping departmental innovation. It means ensuring that the software bought in the margins does not become the part of the estate the board cannot govern.