Tech audit decision guide · checked 29 July 2026
When do you need a tech audit
Commission one when a specific decision has material downside, the evidence is incomplete or conflicted, and an independent review can change the decision.
Direct answer
- You need a tech audit when a specific investment, supplier, delivery, leadership, continuity, or build-versus-buy decision carries material downside and the current evidence is not reliable enough.
- Do not buy a generic “technology health check”. Select the intervention first: decision-oriented tech audit, internal IT assurance, security assessment or penetration test, compliance or certification audit, code review, or technical due diligence.
- A useful audit starts with a decision owner, boundary, exclusions, criteria, evidence request, independence declaration, and definition of closure.
- There is no defensible universal price or duration. A comparable proposal must name systems, environments, access, interviews, evidence quality, reporting, specialist work, and follow-up.
The commissioning rule
A useful audit begins with a decision.
A technology estate can be old, complicated, or unpopular without justifying an independent audit. The stronger trigger is a decision that could change after evidence is tested: renew this supplier, fund this platform, acquire this company, replace this system, change the team, or accept this risk.
The IIA Global Internal Audit Standards provide a useful structure even when the work is not formal internal audit: assess relevant risks, agree objectives and scope, establish evaluation criteria, document a work programme, communicate findings, agree action plans, and monitor implementation.
That structure prevents a familiar failure. A provider reviews whatever is easiest to access, produces a traffic-light score, and leaves management with observations that do not answer the decision.
Choose the intervention
“Tech audit” can mean six different products.
| Intervention | Use it when | Expected answer | Do not confuse it with |
|---|---|---|---|
| Decision-oriented tech audit | A business decision depends on contested or incomplete technology evidence | Options, risks, consequences, confidence, and an owned recommendation | A certificate or general health score |
| Internal IT assurance | Leadership or an audit committee needs assurance over governance, controls, or operations | Whether agreed controls and criteria are designed and operating as required | A product roadmap |
| Security assessment or penetration test | You need threat, vulnerability, configuration, or exploit evidence | Security findings within an explicit technical scope and test method | Broad commercial due diligence |
| Compliance or certification audit | A law, customer, policy, or scheme names formal criteria and assurance requirements | Conformity against those criteria, issued by an appropriately qualified party where required | Informal readiness advice |
| Code review | A codebase, component, release, or maintainability question is the decision boundary | Code-level findings and remediation guidance | Whole-company technology assessment |
| Technical due diligence | An investment, acquisition, or financing decision requires transaction evidence | Transaction risks, capabilities, dependencies, and implications for the deal thesis | A routine operational review |
Trigger selector
Start with the event, then select the smallest sufficient review.
| Trigger | Decision to name | Likely review | Evidence that should change the decision |
|---|---|---|---|
| Major investment | Fund, stage, redesign, or stop? | Decision-oriented tech audit | Capacity, dependencies, delivery evidence, operating cost, and credible options |
| Acquisition or investment transaction | Proceed, reprice, protect, or walk away? | Technical due diligence | Deal-thesis risks, product and platform capability, security, team, ownership, and separation needs |
| Supplier renewal or replacement | Renew, renegotiate, compete, migrate, or accept? | Supplier-focused tech audit | Contract, service performance, architecture dependency, data portability, exit plan, and switching constraints |
| Persistent delivery stall | Change scope, architecture, operating model, supplier, or leadership? | Decision-oriented tech audit | Flow data, backlog and release history, architecture constraints, decision rights, and interviews |
| Leadership transition or key-person risk | Transfer, recruit, restructure, or stabilise? | Continuity and operating-model audit | Access, ownership, runbooks, decision history, role concentration, and recovery exercises |
| Security incident or credible threat | Contain, investigate, recover, and reduce recurrence? | Incident response first; specialist security assessment when stable | Logs, affected assets, attack path, control evidence, and recovery status |
| Regulated or contractual requirement | What assurance is required and by whom? | Compliance or certification audit | Explicit criteria, product boundary, qualified assessor, evidence rules, and permitted statement |
| Major build-versus-buy decision | Build, buy, extend, partner, or defer? | Decision-oriented architecture and supplier review | Requirements, lifecycle cost assumptions, integration, security, skills, reversibility, and exit |
Audit decision gate
Commission the audit only if you can answer yes to these five questions.
✓
Is the decision specific, with an accountable owner and review date?
✓
Could a wrong decision create material financial, operational, security, customer, or transaction downside?
✓
Is important evidence missing, disputed, supplier-controlled, stale, or affected by a conflict of interest?
✓
Can an independent reviewer obtain enough access and apply explicit evaluation criteria?
✓
Can the organisation change the decision or fund action when the evidence warrants it?
When not to audit
An audit is the wrong tool when the answer cannot be used.
Do not commission a general tech audit when nobody owns the decision, access will be withheld, management has predetermined the answer, or there is no route to act. Resolve those constraints first or commission a narrower evidence-gathering task.
Use immediate incident response for an active security event. Use a qualified conformity or certification body when a scheme requires one. Use legal, accounting, valuation, privacy, safety, or other specialist advice where the conclusion sits outside the technology reviewer’s competence.
A code review is enough when the decision is genuinely confined to code. Transaction technical due diligence is the better product when the evidence must test an investment thesis and inform deal protections.
One-page charter
Define a decision-ready tech audit in eight steps.
01
Name the decision
Write the decision, owner, options currently available, downside of error, decision date, and people who will rely on the conclusion.
02
State the risk hypothesis
Record what may be wrong, why it matters, what is already known, what is contested, and which evidence could disprove the concern.
03
Set the boundary
Name products, entities, suppliers, systems, environments, teams, dates, locations, and data inside scope. List exclusions and dependencies explicitly.
04
Choose the criteria
State what the evidence will be evaluated against: contract, policy, architecture principle, service objective, framework, regulation, or approved business requirement.
05
Freeze the evidence request
List artefacts, repositories, environments, interviews, samples, observation periods, access conditions, and how unavailable or unreliable evidence will be recorded.
06
Declare independence
Identify who commissions, pays, supplies evidence, reviews drafts, and may benefit from the result. Record conflicts, constraints, and specialist qualifications.
07
Define the finding record
Require observation, criterion, evidence, consequence, confidence, option, owner, and review trigger. Separate fact, interpretation, and recommendation.
08
Define closure
Agree decision forum, acceptance process, action owner, funding path, review trigger, closure evidence, residual-risk acceptance, and escalation for overdue action.
Evidence request
Organise the evidence request by decision domain.
| Domain | Useful evidence | Question it can test |
|---|---|---|
| Architecture | System context, data flows, environments, interfaces, dependencies, capacity and recovery design | Can the system meet the intended change, scale, resilience, and separation needs? |
| Delivery | Roadmap, backlog history, lead time, releases, incidents, quality signals, work in progress, and decision logs | What constrains reliable delivery, and which intervention addresses it? |
| Security | Asset and data inventory, access model, vulnerabilities, incidents, backups, recovery tests, and supplier controls | Which risks are evidenced, and what specialist testing is still required? |
| Suppliers | Contracts, service levels, change requests, invoices, performance reviews, subcontractors, portability, and exit plans | What is controlled, dependent, reversible, and commercially exposed? |
| Costs | Run cost, licences, cloud usage, support, change spend, capital assumptions, and migration estimates with sources | Which option has supportable lifecycle assumptions? |
| Ownership | IP records, repository and tenant ownership, admin access, roles, licences, data rights, and decision rights | Can the organisation control, change, and transfer its technology? |
| Continuity | Runbooks, key-person map, recovery objectives, exercises, support rotas, and knowledge-transfer records | Can critical services continue through failure or transition? |
| Decision history | Architecture decisions, board papers, exceptions, risk acceptance, prior audits, and unresolved actions | Why does the current state exist, and which assumptions remain valid? |
Supplier and exit evidence
A supplier review is incomplete without a credible exit.
The NIST Cybersecurity Framework 2.0 includes governance of cybersecurity supply-chain risk. NIST’s CSF frequently asked questions explain that organisations can use the framework to establish supplier requirements and prioritise investments. The CISA Software Acquisition Guide and Secure by Demand add acquisition questions for software buyers.
Security criteria are only part of the decision. The UK government’s Digital, Data and Technology Playbook calls for exit activities, milestones, resources, roles, risk management, dependencies, and transfer of assets, data, and knowledge. Test the exit plan against the actual architecture, rights, access, skills, and time assumptions.
The Technology Code of Practice is another practical source for technology choices, open standards, security, data, cloud, accessibility, and sustainability. Use only the criteria relevant to the decision under review.
Compliance next step
Get a compliance check on: When do you need a tech audit
Send us where your site stands today. We reply with the risks that carry real exposure, not a generic checklist.
Finding quality
A useful finding becomes a decision record.
| Finding field | What to record | Why it matters |
|---|---|---|
| Observation | What was observed, where, when, and by whom | Keeps the finding testable |
| Criterion | The requirement or expectation and its authoritative source | Separates preference from deviation |
| Evidence | Artefacts, interviews, samples, tests, limitations, and conflicting material | Shows the basis and evidence boundary |
| Consequence | Decision, service, customer, security, cost, or transaction implication | Connects technology to material downside |
| Confidence | High, medium, or low with the reason and missing evidence | Prevents false certainty |
| Option | Accept, avoid, reduce, transfer, investigate, renegotiate, replace, or defer | Makes alternatives visible |
| Owner and trigger | Accountable person, dependency, due date or review event, and escalation | Turns advice into governable action |
| Closure evidence | Test, artefact, approval, transfer, or measured result required to close | Prevents “done” without verification |
Cost and duration
Price follows the evidence boundary.
There is no universal tech-audit price or delivery window that remains meaningful without scope. Ask providers to price the same decision, boundary, systems, environments, locations, access model, interviews, sampling, specialist tests, evidence quality, report fields, workshop, and follow-up.
Separate the independent review from remediation, penetration testing, legal analysis, certification, travel, third-party fees, data extraction, implementation, and repeat testing. Record assumptions and a change-control rule for missing systems or late evidence.
A smaller quote may omit the evidence needed for the decision. A larger quote may include work that belongs in implementation. Compare the conclusion each proposal is permitted to support, then compare price.
Common questions
Tech audit questions, answered from the decision outward.
When does a company need a tech audit?
When a specific technology-dependent decision has material downside, relevant evidence is missing or conflicted, an independent reviewer can test it against explicit criteria, and the decision owner can act on the result. Messy technology alone is insufficient.
What is the difference between a tech audit and technical due diligence?
A decision-oriented tech audit can support operational choices such as supplier renewal, platform investment, delivery recovery, or leadership transition. Technical due diligence tests technology evidence for an investment or acquisition thesis and may inform pricing, protections, integration, or a decision not to proceed.
What should a tech audit include?
A decision and owner, risk hypothesis, boundary and exclusions, evaluation criteria, evidence request, independence and conflicts, work programme, findings with confidence and consequence, options, action ownership, review trigger, and closure evidence.
How much does a tech audit cost?
There is no responsible universal range. Cost depends on the decision, systems and environments, access, interviews, sampling, evidence quality, specialist work, reporting, workshops, and follow-up. Give each provider the same charter and ask them to separate review from remediation.
How long does a tech audit take?
Duration follows the scope and evidence access. A proposal should state the review period, dependencies, interview and test effort, draft and challenge process, decision date, and what happens when evidence is late or unavailable.
What happens after a tech audit?
The decision owner accepts, rejects, or requests more evidence for each material finding, selects an option, funds owned action, records residual risk, and reviews closure evidence at a defined date or event. A report is not closure.
Some Tech Work scope
We start with the decision charter.
Some Tech Work scopes independent technology reviews for business decisions. The proposal names the decision, evidence boundary, criteria, access, interviews, specialist dependencies, finding fields, exclusions, decision forum, and closure path before work begins.
For an operational investment, supplier, delivery, continuity, or build-versus-buy decision, see our tech audit service. For an acquisition or investment transaction, use technical due diligence. Security testing and formal compliance assurance are scoped as distinct specialist interventions.
Decision memo
Take the commissioning questions into the decision room.
Free resource
Download the technical audit decision memo
A one-page memo for founders and operators: name the decision, select the review, define the evidence boundary, and assign closure.
Loading form…
Written by
Vineet Talwar
Co-founder, Tech & Operations at Some Tech Work. WordCamp speaker across Europe and Asia, and host of the WP Shoutout podcast.
Start here
Ready to talk.Book a short diagnostic.
Tell us what needs fixing
We read every brief and reply within one business day.
Prefer to talk first?or request a tech stack audit →or email us directly →
Not sure where to start? Send the stuck decision, workflow, or page. We will say whether you need a diagnostic call, a tech stack audit, or a different first step.