The previous vendor left in March. What they left behind: a repository, a server nobody dares to restart, and a three-page document that says "see code". Now the operations manager has to decide whether to keep investing in that system or replace it, and has no way of knowing what's inside.
This is the most common reason a company looks for software development consulting. It doesn't need anything built yet. It needs someone from outside to open the system it already has and say, with evidence, what shape it's in. That's a code audit, or a technical software assessment. Done well, it gives you a map of risks with priorities and rough costs. Done badly, it's a long PDF with a thousand warnings from an automated tool that nobody knows how to read.
This article covers what a serious assessment looks at, what you should get at the end, and when it makes sense to ask for one. If what you want is to modernize an old system with help from AI, we cover that separately in consulting for legacy modernization; the assessment is usually the step before.
When to ask for a technical software assessment
There are four moments when an audit easily pays for itself:
- Before buying or inheriting a system. If you're acquiring a company, a product or a source code license, the assessment tells you how much technical debt comes bundled into the price.
- When switching vendors. The new team needs to know what it's walking into, and you need a baseline so you don't end up paying later for problems that were already there.
- Before scaling. If the system is going from 50 to 500 users, or opening up to external customers, it's worth knowing where it will break first.
- When something is already failing. Recurring outages, simple changes that take weeks, or a security incident are symptoms. The assessment looks for the cause.
There's also a regulatory reason. Chile's Law 21.719 requires anyone responsible for personal data to adopt security measures suited to the state of the art, the costs and the risk of the processing (article 14 quinquies). Its entry into force is currently set for December 1, 2026, and a bill in Congress proposes pushing it back to October 15, 2027. As of November 6 that bill had not been finally approved, according to Eguiguren Abogados' tracking. Delay or not, it's hard to show a system is protected if nobody has ever reviewed it.
What a code audit reviews
A useful audit looks at the whole system, and the code is only one part of it. These are the areas that should show up in the report:
| Area | What gets reviewed | Typical red flag |
|---|---|---|
| Architecture | How responsibilities are split across modules, services and the database; where the single points of failure are | All business logic living in stored procedures or in one file thousands of lines long |
| Code quality | Duplication, complexity, conventions, error handling | The same calculation copied in five places, each slightly different |
| Dependencies | Libraries and frameworks in use, their versions, known vulnerabilities and support status | A framework that hasn't had a security update in years |
| Security | Access control, authentication, secrets handling, injection, configuration | Passwords or API keys hardcoded in the source |
| Testing | Whether automated tests exist, what they cover and whether they run | "Users do the testing, in production" |
| Deployment and operations | How a change reaches production, backups, logging, monitoring | Manual deployments only one person knows how to do |
| Documentation | Whether someone new could understand, install and change the system | The only manual is the memory of the developer who left |
For security, a good reference is the OWASP Top 10:2025, the list of the most critical risks in web applications. The 2025 edition puts broken access control at number one and adds a new category on software supply chain failures, which is exactly what the dependency inventory checks. If you need more detail, OWASP ASVS defines verifiable requirements by assurance level.
For overall quality, ISO/IEC 25010:2023 describes a product quality model that includes, among other things, maintainability and security. You don't need to certify anything, but using a known model keeps the report from depending only on the auditor's taste.
Automated tools and human review
Static analysis and software composition tools (the ones that check dependencies) are fast and cheap. They go through the repository and catch known patterns, like a SQL query built by concatenating strings or a library with a published vulnerability.
The problem is noise. A single run can return hundreds of findings, several of them false positives, and almost none sorted by what matters to your business. And there are things a tool can't see: that the commission calculation rule is implemented wrong, that a warehouse user can approve credit notes, or that the whole system depends on a scheduled task on a server nobody documented.
So a serious assessment uses both. The tool does the sweep; an experienced person filters, confirms, interviews the people who use the system and turns findings into concrete risk. If someone offers you an audit that's just an automated report with their logo on it, you're paying for something you could run yourself.
What deliverables you should get
At the end of the assessment you should have, at minimum:
- An executive summary of one or two pages, written for whoever makes the decision rather than whoever writes the code: overall state, the three to five main risks and a recommendation (keep, refactor in parts, replace).
- A prioritized list of findings, each with evidence (file, line, screenshot or test), impact, likelihood and estimated effort to fix.
- A dependency inventory with versions, support status and known vulnerabilities. Some vendors deliver it as an SBOM (software bill of materials), which helps if you later want to monitor it continuously.
- A diagram of the current architecture, even a simple one.
- A roadmap split into what's urgent (weeks), what's important (months) and what can wait.
Ask for the report to separate facts from opinions. "This library has a published vulnerability" is a fact. "The architecture won't scale" is an opinion, and it should come with the reasoning behind it.
How to prepare and how long it takes
Timing depends on size and access. A mid-sized web system with a tidy repository can be assessed in a couple of weeks; a system with several components, ERP integrations and no documentation will take longer. In practice, what slows an audit down most is permissions: waiting days for repository access, a copy of the database, or someone who can explain the business.
To keep it moving, have these ready:
- Read-only access to the full repository, history included.
- A copy of the environment or, if there isn't one, supervised access to the test environment. Be careful about using real customer data there; see what Law 21.719 says about production data in test environments.
- A signed non-disclosure agreement before you hand anything over.
- One or two business people who can explain the critical processes.
- Your contracts with the previous vendor, so you know who owns the code.
And decide from the start what decision you want to make with the result. Auditing to negotiate a purchase needs a different focus than auditing to plan next year's maintenance, and the report should reflect that.
Frequently asked questions
Does a code audit replace a penetration test?
No. A penetration test attacks the running system from outside; the audit reviews it from inside. They complement each other: the audit finds causes, and the pentest confirms what can actually be exploited.
Who should do the technical software assessment?
Someone who didn't build the system. The team that wrote it knows the code well, but it's naturally biased when judging its own work. An independent third party gives a more useful opinion, especially if you'll use it to negotiate or to switch vendors.
What if the answer is "it needs replacing"?
Reports rarely conclude that everything is lost. Usually some parts are worth keeping, like the data model or certain integrations, and others are better rebuilt. With the prioritized list you can replace in stages instead of betting everything on one big project.
Let's talk about your system
At Disrupsoft we build custom software with Azure, Power Platform, Angular and Node.js, and before proposing changes to an existing system we like to understand what's really inside it. If you're about to switch vendors, buy a system or scale one that's hitting its limits, tell us about your case and we'll work out where to start.
