Hello! Spring is traditionally a time for cleaning and organizing. One of the most effective ways to start tidying up is to properly assess your current situation, and that’s where an audit can help. According to Wikipedia, it’s an inspection, analysis, or evaluation of an economic entity. In essence, you can audit almost anything – some do it for finances, while, for example, my colleague Justina even conducts audits to evaluate user experience.
In the same way, we inspect IT systems. Such audits can be divided into two main groups: internal, which we carry out for ourselves, and external – when a client comes to us seeking to improve their existing systems so that they run reliably and make the most efficient use of available resources (whether human, server, or code).
Of course, encyclopedias also mention state audits, but let’s leave those to the serious guys with big beards.
When is a system or code audit needed?
There isn’t a single definitive answer to when is the best time to review your “garden of systems,” but I’m convinced it’s necessary to check in as often as possible. Why? Because knowledge should be shared, and also because new best practices are constantly emerging. Looking at it more broadly, I’d even call spoken criticism or feedback a kind of micro-audit – pointing out what could work better.
Meanwhile, clients usually come to us wanting to clarify a few situations in their projects. First – when they change system developers (hire an in-house team or switch companies) and want to see what was done incorrectly. Second – when they want to implement changes and can’t understand why their projects take so long to complete. By the way, there can be many answers to this: from the system itself to the specifics of requirements.
How is a technical audit carried out?
A technical audit is usually performed by specialists from two or three fields – most often devops and developers. Their main goal is to determine the status of the system: is it still maintainable, or is it time to throw it out and start building something new? A secondary goal is to identify the critical points that hinder smooth operation.
An audit is like a retrospective – the questions aren’t “who did this” or “why,” but “what can we do differently so that the project runs properly.” The most important thing is not to forget that this isn’t about finding scapegoats, but about highlighting what could be improved.
During an audit, we essentially swap roles with the team – a technical person comes in and asks: “Why was this done this way? Could X solution have been used instead? Why are you using Y, when Z works faster?”
What is evaluated during an IT audit?
Frameworks and versions
First, we identify which framework(s) the project is running on. In practice, we see everything: from very old or home-grown frameworks that are no longer maintained, to the latest versions. The worst cases are when the framework is outdated, and even worse – when several frameworks are mixed together. This usually happens in companies that lack established best practices.
Since I come from the PHP world, here’s an example: imagine a project built on Yii (which is old), and someone decides to add Laravel components. It may work in practice. But then a new developer joins, a hardcore Symfony fan, and adds some Symfony components. What framework do we have now? Which version? An audit helps unravel such messes.
Code quality
We look at whether coding standards and practices are followed in delivering code to production. If some parts use snake_case and others camelCase, that signals a lack of standards. If pull requests aren’t reviewed, tests aren’t written, static analysis isn’t done, and bugs aren’t caught before release – that’s a big problem.
Here, “continuous integration” is crucial, with emphasis on “continuous.” It’s the system that scans every part of the code, runs tests where needed, performs static analysis, or deploys changes to staging or production. Because even good intentions in programming break down with “I’m tired” or “this task is obvious, no need to document it.”
Code reviews also get a lot of focus. They don’t need to be perfect, but they need to exist. For instance, in one audit we found lots of swear words in code comments and even passwords hardcoded in the code itself. Reviews would have flagged that immediately.
Maintainability
We evaluate how easy it is to maintain the system and add new features. What needs fixing to make it smoother? Are libraries used? Are people reinventing the wheel? Are tests written? If yes – success. If not – we outline what could be done differently.
Security vulnerabilities
Probably the most important part, and needs little explanation: where are the simple risks of intrusion, damage, or crashes? We don’t play Mr. Robot with fancy hacks – we just check if there are gaps in framework usage, code, firewalls, etc.
Infrastructure
We assess how it’s set up. Sure, it’d be nice to see Kubernetes or auto-scaling resources, but reality is usually different. Often clients overpay for unused capacity, because the OS or related software (usually PHP) is so outdated it’s not even worth updating.
We usually start this section by drawing a diagram: which machines run what OS and software, their load levels, and versions. From this we say what we’d do if we owned the project.
Audit conclusions
Like any decent study, an audit ends with conclusions divided into two categories:
-
Technical Action Points – urgent tasks that need to be addressed right away. Then follow tasks like refining technical processes, cost optimization, and improving code quality.
-
Team Action Points – recommendations for the team itself: maybe more diverse skills are needed? More testing resources? A technical lead? If the team is fine as is, we skip this part.
Common problems
Although each case is unique, from experience we see recurring issues. At the start of a project, make sure:
-
Pull requests are properly reviewed.
-
If you don’t have CI, implement it.
-
Tests, tests, tests – ideally a pyramid: mostly unit tests, fewer integration tests, and the fewest E2E tests.
-
Set reminders to periodically review servers, versions, and infrastructure relevance.
Are there projects that don’t need auditing?
We all know perfect projects don’t exist. Every audit uncovers something to comment on – and the other side something to justify. But it’s important to understand: the audit isn’t about defending yourself or making excuses.
We also don’t assume we know all the details and quirks of the system. Everything we do in an audit should be seen as sharing experience and offering help. Ultimately, the only real question an audit should answer is: what can we do to make the project as good as possible?
