The word advisory hides a great deal. At least six different engagements sit under it, with different decision rights, different objects and different ways of breaking. Separating them by what they actually settle is the first useful thing a buyer can do.
What each kind of technology advisory engagement settles
| Engagement | What it settles | Who holds the decision | Evidence it leaves behind | Characteristic failure |
|---|---|---|---|---|
| Standards and conformity advisory | Whether a product can claim conformity with a designated standard | The developer, against the regulator's framework | Test evidence, technical file, version history | A standard is bought and never applied |
| Government procurement and assurance advisory | Whether a technology meets the technology code of practice | The accounting officer, inside spend controls | Business case, hosting assessment, accessibility testing record | The code is filed as documentation and never used as design criteria |
| Regulator-facing technology advice | What a changing technique does to privacy or safety | The commissioner or regulator receiving it | Technical briefing, with no binding effect | The advice is read as if it were a decision |
| Mandated technology compliance | Which detection technology a service must use | The regulator, under statutory power | Accreditation against published minimum standards of accuracy | Accreditation capacity lags the obligation |
| Finance systems advisory | What becomes the system of record | The finance director | Selection report, migration plan, user acceptance testing | A stack is recommended that the client cannot operate |
| Innovation and strategy advisory | Where the next tranche of investment goes | The executive team | Readiness assessment, prioritised roadmap | A roadmap ships with no named owner |
The first two rows explain consulting services where the customer keeps the decision right. The commissioner or the regulator manages it in the third and fourth rows, and regarding those engagements as ordinary guidance leads to losses in budgets and reputations.
Advisers propose; someone else disposes
The Technology Advisory Panel at the Investigatory Powers Commissioner's Office provides the clearest statement of the advisory boundary in UK public life. It was set up under the Investigatory Powers Act 2016 to advise the Commissioner and the Judicial Commissioners on the impact of changing technology and on techniques for using investigatory powers while minimising privacy interference. The same page states that the panel is not a decision-making body and that its advice cannot constrain any decision of the Judicial Commissioners. Its members are appointed for technical depth: cryptography, cyber security, probability, human-data interaction.
That sentence about constraint belongs in every engagement letter. A consultant who has not recorded the limits of their guidance has not defined the engagement.
Ofcom's Technology Notices framework runs the opposite way. Under section 121 of the Online Safety Act 2023, Ofcom can require a provider to use a specific technology to tackle terrorism or child sexual exploitation and abuse content, or to develop technology to tackle the latter, where it decides that is necessary and proportionate. Any technology required this way must be accredited against minimum standards of accuracy set by the UK Government, after advice from Ofcom. Here advice feeds a standard, and the standard feeds enforcement. The consultant's result becomes a legal document, which is a different kind of accountability from the one most advisory firms sell.
Standards are a budget line before they are a technical option
The AI and Digital Regulations Service guidance for health and social care developers applies standards when a product enters the market: meeting them is an efficient way to demonstrate the reliability and quality of a digital technology to regulators and adopters. Designated standards, recognised by government in part or in full, let a developer claim presumption of conformity, and demonstrating compliance helps them reach the market. The same guidance says that standards are not open access and require payment, with the cost built into budgeting, and that the cost of ignoring recognised standards shows up as inefficient development, poor risk management and weak evidence gathering.
The escape route is narrower than it first appears:
You can meet the legal requirements without following specific standards. However, you would need to provide evidence that your alternative method is robust, appropriate, and not inferior to the standardised approach.
The guidance adds that it may be challenging to find an approved body willing to assess a technology against a non-typical set of criteria. The bespoke route is limited by a shortage of willing assessors.
For public sector buyers, the Government Digital Service and Central Digital and Data Office collate the guidance supporting the technology code of practice, the set of criteria used to design, build and buy government technology. Accessibility, APIs, cloud hosting, open standards, legacy migration, security and digital inclusion all sit inside that vocabulary. Advisory work on a government programme is an argument conducted in it.
The finance function evaluates the value of advisory services.
Finance systems advisory has the advantage of a scoreboard. BDO's technology advisory practice works on selection, implementation and managed support for cloud accounting systems including Xero, iplicit and QuickBooks, and on health checks that end in actionable recommendations for an existing stack. It cites research with the ACCA showing finance leaders using advanced analytics to drive decisions outside the traditional finance remit, in customer experience, supply chain, talent and sustainability. That is a claim about the buyer as much as the tool, and it changes the brief: the system of record is being asked for data the finance team does not own.
Sopra Steria arranges the same territory into three pillars, innovation, insight and technology, and sells readiness assessment against the ISO 56000-series, ecosystem mapping, vendor and product evaluation, and phased roadmaps tied to measurable value. KPMG UK frames its technology consulting around alliances with Microsoft, Salesforce, Oracle and ServiceNow, and states that it measures those partnerships on the value they deliver. The three sit at different points on one axis: the extent to which the consultant will support the implementation of the recommendation, and for how long.
Discovery breaks without warning and costs a lot
The most common mistake occurs before the recommendation. Accounting Insight News reports that requirements gathering is where technology advisory projects stall, listing incomplete data, too many sources and communication barriers, and noting that requirements shift as discovery continues. The four areas it singles out are client goals captured in the client's own words, application compatibility with the existing stack, data flow between systems, and simplicity. Its risk list is short and familiar: data security and migration, integration problems, low user adoption, scope creep, and refusing to learn from comparable projects.
No risk among those is technical. All of them are contractual. A reader selecting a consultant should ask which of the six engagement types above they are acquiring, who has the decision right, what the consultant will hand over when the work is complete, and which decisions the advice cannot touch.