Technical audit sprint: a bounded evidence pack, not an opinion
A technical audit sprint is a short project with one named mission, a fixed timebox, an agreed ceiling on effort and an explicit end. It answers a question you can state in a sentence: whether a codebase can carry two more years of growth, why a release keeps failing, how exposed an application is. The output is an evidence pack and a decision, not a retainer and not an opinion delivered in a meeting.
Submit a project See the evidence rulesReviewed by David (CEO) · Updated 23 Sep 2026
What a sprint delivers
Every sprint ends with the same seven-part pack, whatever the subject:
What was examined, how, with which access, over what period, and what was deliberately left out.
Each one stated with the evidence behind it, so you can check it or hand it to a third party.
A rating per finding with the reasoning, separating what is dangerous now from what is untidy.
What the sprint could not see, and how that limits the conclusions. Written before the findings are polished, not after.
What to fix, in what order, with the rough effort shape of each item.
Usually three: fix in place, rebuild the affected part, or accept the risk with a named owner and a review date.
A later, narrower re-run against the findings, agreed as its own milestone if you want it.
What can be audited
One mission per sprint. The usual subjects are:
-
Architecture and codebase health
Structure, coupling, test coverage, dependency age, build and release mechanics, and the cost of changing the system.
-
Cloud, reliability and cost
Environment layout, failure modes, recovery, observability gaps and where spend is not buying anything.
-
Security and privacy
Application and infrastructure exposure, identity and access, secrets handling, data flows and retention.
-
Performance and accessibility
Where a system slows under real load, and where an interface excludes people who must use it.
-
Data and integration quality
Correctness between systems, reconciliation, silent failure and duplicated sources of truth.
-
AI, retrieval and agent assurance
Whether an AI feature is evaluated, grounded, bounded and monitored, and what it does when it is unsure.
-
Open-source licensing and provenance
What is in the dependency tree and what its terms oblige you to do.
-
Failed-project health
What actually exists against what was promised, before you continue, replace or stop.
The rest of the catalogue is on the services page. An audit usually precedes one of the build services there.
Good fit and poor fit
Good fit
- You can state the question the sprint must answer in one sentence
- A decision is waiting on the answer, such as invest, rebuild, continue or stop
- Read access to code, environments, logs or documents can be arranged
- You accept that fixing is a separate piece of work, decided after the findings
Another route fits better
- The request is an open-ended review with no decision attached to it
- The answer is already known internally and independent cover is what is wanted
- No access can be granted, so any pack would rest on interviews alone
- Fixing is expected inside the same timebox at no change to scope
What this is not
-
It is not a certification and not a formal attestation
Netbase is an engineering supplier, not an accredited assessor. A sprint does not award a mark, does not attest compliance against a named standard, and must not be presented to a customer, insurer or regulator as if it did. If you need a formal attestation, engage an accredited assessor; a sprint can prepare you by finding and ordering the gaps, but it cannot replace one. Ask any supplier, including this one, to put that distinction in writing before you buy.
-
It is not the remediation
Read-only access is the default and remediation is a separate milestone unless it is explicitly included in the scope from the start. Mixing the two is how audits quietly become open-ended projects, and how the person who found a problem ends up marking their own repair.
-
It is not a staffing arrangement
A sprint is bought as a bounded project with an exit, which is the honest replacement for renting an engineer indefinitely to look into things. The engagement models page explains how that is structured.
Access, and why read-only is the default
An audit needs to see the real thing, but it does not need to change it. Read access to repositories, a non-production environment, logs, dashboards and documentation is normally enough, and write access is requested only where a specific check demands it and you approve that check.
Delivery is remote-first and Netbase stays accountable for the result; a team may combine Netbase staff, approved specialists or disclosed partners, and everyone who will hold access is named to you before the sprint starts. Secure code review and version control, role-based access control and multi-factor authentication for admin dashboards are standard practice, contributors work under NDA, and NDAs and data processing agreements are available on request. Access is granted for the timebox and revoked at the end.
What we will ask for at the start
Write down the question, the decision it feeds and the date that decision is needed. Add what you suspect, what has been tried, who built the system and whether they are available, and any area out of bounds. Naming a suspicion saves the first days, and the pack will say plainly if it was wrong.
Deliverables
- the written mission and scope, including the exclusions, agreed before any access is granted;
- an access and handling plan naming the people, the systems and the duration;
- the evidence pack: method, findings, severity, limitations, prioritized remediation and decision options;
- a findings review session with the people who will act on it, and a record of the decisions taken;
- a remediation scope, if you want one, as its own milestone with its own acceptance criteria;
- an optional retest scope, narrowed to the findings you chose to fix.
How the work is done
-
Fix the mission
Agree the question, the subject, the exclusions, the timebox and the people involved. Nothing starts until this is written down.
-
Take inventory
Establish what exists: systems, repositories, environments, dependencies, data flows and owners. Gaps here become limitations later.
-
Examine and evidence
Run the checks the mission needs, recording the evidence for each finding as it is made, not reconstructing it at the end.
-
Rate, prioritize and decide
Assign severity, order the remediation, set out the options, and hold a review session where you choose what happens next.
Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. A sprint team is small and drawn from the roles the mission needs, usually solution architecture, development, QA and business analysis, with one lead accountable for the pack. The project delivery page describes how milestones, reporting and acceptance work.
Risks and limitations
The single most common cause of a thin pack. Access is treated as a milestone dependency with a named owner and a date.
Anything found outside the mission is logged and reported, not investigated inside the timebox. It becomes a candidate for its own sprint.
A clean finding means the checks that were run found nothing, within the access granted, at that date. The pack says exactly that.
A system under active change needs a retest date, not a longer report.
Each accepted risk carries a named owner and a review date, or it is not an accepted risk.
AI in the audit, and audits of AI
Netbase engineers use AI tools to speed up parts of an audit, such as reading unfamiliar code or summarising dependency trees. Every finding is reproduced and owned by a named engineer before it enters the pack; model output is never a finding on its own, and the method section says where such tools were used.
When the subject of the audit is itself an AI feature, the work is model-agnostic. Netbase works with commercial and open-source AI models chosen per project, and no vendor partnership is implied by anything the pack recommends. The checks look at whether the feature is grounded in approved sources, whether an evaluation set and a threshold exist, whether cost and usage are bounded, what happens on an uncertain answer, and whether a person is in the loop where impact demands it. Where the finding is that the workflow was never designed for automation, the next step is an AI workflow blueprint rather than a patch.
Frequently asked questions
One to three weeks for a single mission is typical. A longer timebox usually means two missions wearing one name.
Only under a separate scope you decide on after reading the pack. Remediation is its own milestone with its own acceptance criteria, and you are free to give it to someone else or to your own team.
No. A sprint can show you where you stand and what to fix, but compliance against a named standard is assessed by an accredited assessor, not by an engineering supplier.
Yes, and the pack will say so in the method section. Where independence has to be visible, use a supplier with no stake in the answer; we will say the same.
Then the pack says so with the evidence, and the options include what replacement would involve. That usually leads to legacy application modernization or custom product engineering.
Yes. A retest is scoped narrowly against the findings you chose to fix, so it is far smaller. If you want continuous checking instead of a point-in-time pack, that belongs in managed operations.
Evidence and related work
The methodology page sets out how Netbase handles evidence, sources and claims, and the anonymized delivery records on the Work page each state what they can and cannot prove. Audit engagements are covered by client confidentiality, so individual packs are never published or quoted.
Ready to name the question?
The next step after a pack is whichever build the findings point at: AI Workflow Automation when the answer is a better process, custom product engineering or modernization when the answer is a better system. Most Netbase projects are agreed as fixed-scope contracts after discovery, and an audit sprint is often what makes that scope honest. Submit a project brief with the question, the systems involved and the date your decision is due. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.