Back Office Cyber Exposure: Your Vendor Is Your Attack Surface

NotPetya did not break into Ukrainian companies. It arrived through an update to their accounting software. That single fact reframed third-party risk for back office operations more effectively than a decade of questionnaires had managed. The compromised channel was M.E.Doc, the tax and accounting package that nearly every company filing in Ukraine was obliged to run, and the payload came down through a signed, trusted, routine update. There was no phishing email to train people against, no firewall rule to tighten, no credential to rotate. The vendor was the attack surface. Back office functions are where this exposure concentrates, and it is rarely mapped. Payroll bureaux hold every employee record and initiate bank payments. Accounts payable outsourcers touch the bank details of every supplier. Expense platforms, e-invoicing agents, tax filing software, benefits administrators, banking connectivity providers and the integrator who maintains the ERP all sit inside the money-movement path. Each is a path in, and most of them received a security questionnaire once, at onboarding, some years ago.

The four exposure types

They are genuinely different and need different controls, which is why a single vendor risk process handles all of them badly. Software in the transaction path. Payroll engines, tax filing tools, e-invoicing connectors, banking integration middleware. Compromise here can alter payment instructions directly, and the update channel is the delivery mechanism. The control is staged deployment, integrity verification and — critically — detection on the output: does anyone check that the payment file that left matches the one that was approved? Service providers with system access. BPO teams, managed service providers, the ERP integrator, offshore finance teams. They hold credentials in your systems, often privileged, often shared, frequently retained long after the engagement scope narrowed. The control is access governance: named individual accounts, time-bound privileged access, quarterly recertification, and immediate revocation on personnel change at their end — which requires them to tell you, which requires a contract clause. Data processors holding your records. Payroll bureaux, benefits administrators, document archiving providers. The exposure is disclosure rather than manipulation, and the consequences are regulatory as well as commercial. The control is data minimisation, encryption, defined retention and a deletion obligation you can actually enforce at termination. Counterparties in the payment instruction chain. Suppliers whose email gets compromised, banks' communication channels, anyone who can plausibly send you new bank details. The control is verification out-of-band against a record you already hold, not a reply to the message that requested the change. Most organisations' third-party programmes address the third type reasonably well, because privacy regulation forced it, and the first, second and fourth barely at all.

Why questionnaires do not work here

A vendor security questionnaire measures what a vendor says about its controls at a point in time, and it is answered by a sales engineer. It does not tell you whether your integrator's support engineer still has domain administrator rights, whether your payroll provider's update channel is signed and verified, or whether a change to supplier bank details in your ERP triggers any alert at all. The more useful discipline is to invert the question. Rather than assessing the vendor's posture, map what each vendor can do to you — the specific actions available to them given their access — and then ask whether you would detect it. A payroll provider who can submit a payment file is a payment-authorisation risk regardless of their certification status. An integrator with standing administrative access is a lateral-movement risk regardless of their ISO certificate. Control the access and instrument the outputs; treat the questionnaire as background rather than as the assessment. One specific practice worth adopting: read the exceptions section of any audit report a vendor provides. The certification tells you a scope was assessed; the exceptions tell you what was found. Most people file the first page and never reach the findings.

Practical Guidance for Vendor Security Assessment

• Map vendors by what they can do, not by what they spend. Anyone in the payment instruction path or holding privileged access is tier one regardless of contract value.
• Inventory third-party accounts in your systems and recertify quarterly. Standing privileged access held by integrators and support teams is the most common unowned exposure in the estate.
• Require named individual accounts and notification of their personnel changes. Shared service accounts make attribution impossible and offboarding theoretical.
• Stage vendor updates for business-critical software. Phased deployment with a holdback group is the only practical defence against a compromised update channel.
• Instrument the output, not just the access. Reconcile the payment file submitted against the batch approved; alert on supplier bank detail changes and on new payees.
• Verify bank detail changes out-of-band against records you already hold. Never against contact details supplied in the request itself.
• Read the exceptions section of every audit report. The certificate is marketing; the findings are the assessment.
• Write exit and deletion obligations into the contract and test them at termination. Data you cannot compel deletion of is a liability with no expiry date.

The Regional Angle

Gulf back office operations carry a distinctive third-party profile, and the aggregate exposure is higher than most organisations have mapped. The integrator-managed estate is the defining feature. A large share of regional ERP, HR and finance systems are implemented and operated by systems integrators under multi-year contracts, which concentrates privileged access in third-party hands to a degree unusual in other markets. In practice this frequently means shared administrative credentials, remote access from the partner's own network or from offshore delivery centres, and access provisioned during implementation that was never reduced afterwards. Two questions worth putting in writing: can you revoke that access unilaterally within an hour, and do you have a current list of every individual at the partner who holds it? The government and quasi-government interface layer is the second, and it is under-examined. Regional operations depend on mandated channels and intermediaries — wage protection system submissions through banks or exchange houses, e-invoicing clearance platforms, customs and trade portals, visa and labour processing through PROs and typing centres, national identity verification services. Several of these are effectively compulsory, which removes the option of not using them, and some of the intermediaries in the chain are small operations handling highly sensitive identity and payroll data. The PRO and typing centre channel deserves particular attention: passport copies, visa documents and employee identity files routinely move through WhatsApp and personal email in this chain, entirely outside any vendor risk register. Third, regional shared service centre structures create a layered arrangement that questionnaires rarely reach. A group may run finance operations from Dubai or Cairo for entities across several countries, with the hub itself using offshore providers for transaction processing — which means fourth-party access to group systems that the second party may not have disclosed. Ask directly about subcontracting and onward access rights, and make disclosure of them a contractual obligation. Finally, the regulatory framing has strengthened. Central bank cyber and outsourcing frameworks for regional financial institutions, national cybersecurity authority requirements in the UAE and Saudi Arabia, and data protection legislation across the region and in DIFC and ADGM now impose specific third-party due diligence, contractual and notification obligations. Outsourcing to a provider outside the jurisdiction may itself require notification or approval in regulated sectors. The practical consequence is that the vendor register has become an auditable artefact rather than an internal document — and most regional registers do not currently list who holds privileged access.

The objection worth taking seriously

The honest problem with third-party risk management is that it has become a compliance ritual with limited demonstrated effect on outcomes. Organisations exchange questionnaires that nobody validates, collect certificates that describe a scope rather than a posture, and impose contractual security obligations that would take litigation to enforce and would not restore the data anyway. Meanwhile the incidents keep arriving through routes the process did not cover — a compromised update, a support engineer's credentials, a subcontractor nobody disclosed. There is a reasonable case that the effort spent on assessment paperwork would deliver more risk reduction if redirected entirely into access control and detection on your own side, where you have actual authority. There is also a genuine power asymmetry. A mid-market company cannot dictate security terms to a major software vendor, a bank's payment channel, or a mandated government platform. Told to "only work with vendors who meet your standards", most regional finance functions would have to stop filing taxes and paying salaries. The realistic posture is to accept the dependency, reduce what each dependency can reach, and detect misuse — rather than to pretend the relationship can be governed into safety. And a scoping caution: the tail is long and the effort has to be proportionate. An organisation with two hundred suppliers cannot meaningfully assess all of them, and attempting it produces thin coverage everywhere instead of real control over the ten relationships that could actually hurt you. Identify those ten — payment path, privileged access, sensitive data at scale — do serious work there, and handle the rest with contractual baselines and nothing more.

Common Questions

Which vendors should be treated as highest risk?

Anyone who can initiate or alter a payment, anyone holding privileged access to core systems, and anyone holding employee or customer identity data at scale. Contract value is a poor proxy — some of the most dangerous access sits in inexpensive relationships.

How do you defend against a compromised software update?

Staged rollout with a holdback group, integrity verification where the vendor supports it, and detection on the outcome — particularly reconciliation of payment files and alerting on unexpected outbound connections after an update. You cannot prevent it; you can limit blast radius and shorten discovery time.

What is the most commonly missed third-party exposure?

Standing privileged access granted during implementation and never reduced, held by an integrator whose current personnel list you do not have. It is almost universal and it is fixable in a quarter.

Does AI change vendor risk in the back office?

It adds two things. First, a new class of subprocessor that most registers do not capture: when a payroll, expense or AP platform adds AI features, your data may be processed by a model provider that is not named in your contract, in a jurisdiction your data map does not include, with retention terms you have not reviewed. Ask every back office vendor which model providers they use, where inference runs, what is retained, and whether your content trains anything — and require notification when that changes. Second, it has made the fourth exposure type substantially worse: fraudulent payment instructions and bank detail changes are now fluent, contextually accurate and available in Arabic and other regional languages, and voice cloning defeats the callback verification many finance teams rely on. The countermeasure is procedural rather than technical — verify against details you already hold, require two people for changes to payment data, and stop treating a recognised voice as authentication.

---

Vendor Security Assessment — map what each vendor can do to you, then check whether you would detect it; the questionnaire is background, the access list is the assessment.