What a technical security audit is
It's a review of your website, server, and everything connected to them for common, well-known problems. We look at the site through the eyes of both a developer and an attacker: where someone could get in without permission, what data could leak, and what would break first.
It's important to understand the limits. A technical audit is not a certification or a legal opinion on compliance with standards. It also doesn't replace full penetration testing for banks or large platforms. But for the vast majority of business websites and online stores, a technical audit covers the main real-world risks.
What the audit covers
- Software: versions of your CMS, framework, modules, themes, libraries, PHP, and database.
- Access: accounts in the admin panel, on the server, with your hosting provider, in the database, and in third-party services.
- Code: handling of forms and user data, file uploads, and protection against the most common attacks.
- Server: HTTPS, open ports, file permissions, and system files and pages exposed to the outside.
- Backups: whether they exist, where they're stored, and whether you can actually restore from them.
- Signs of compromise: unknown files, hidden links, and suspicious code changes.
Who needs an audit and when
An audit is especially worthwhile in these situations:
- you inherited the site from another contractor and don't know what's "under the hood";
- the site hasn't been updated in a long time, and your CMS and modules have gone through several new versions;
- you've noticed warning signs: unfamiliar ads, redirects to other sites, warnings in search results or the browser, a sudden spike in server load;
- the site stores customers' personal data, accepts payments, or has user accounts;
- you're preparing for a major ad campaign or investor due diligence.
If your site is regularly maintained by a team that already keeps an eye on security, a standalone audit is needed less often — for example, after major changes.
Why updates are half of security
CMS and module developers constantly find and patch vulnerabilities. As soon as a fix is published, details of the vulnerability become public, and automated bots start scanning for sites that haven't updated. That's why an old module isn't just "outdated" — it's an open door.
At the same time, updating everything blindly is risky too: a new module version can conflict with custom code and break checkout. So we run updates on a staging copy, test the key user flows, and only then push them to the live site. If a module is no longer supported by its author, we suggest a replacement.
One-time audit or ongoing updates
A one-time audit gives you a snapshot of where things stand today and a plan of fixes. It makes sense when you need to understand your risks quickly, or when your site is maintained by an in-house team that wants an outside perspective.
Ongoing maintenance means scheduled updates, access reviews, and re-checks after changes. It costs less than cleaning up after a breach and is usually part of website support. On the server side, we handle updates as part of server administration.
What you get
A report that makes sense to non-technical people too. For every issue we find, we describe:
- what exactly is wrong and where we found it;
- what it puts at risk for your business: customer data leaks, lost sales, lower search rankings;
- how urgently it needs to be fixed;
- how to fix it and whether that can be done without taking the site down.
The report is yours to keep. We can make the fixes ourselves or hand the recommendations over to your developers.
What to prepare on your side
- access to the admin panel, server or hosting account, and, if possible, the code;
- a list of people and companies who currently have or previously had access to the site;
- details of any suspicious incidents, if there were any;
- a list of third-party services connected to the site: payments, CRM, email marketing, analytics.
Common problems we find
- Modules and themes that have had several updates released, none of which were ever installed.
- A shared admin password used by several people, including former employees.
- Database dumps sitting in a publicly accessible folder on the site.
- An old PHP version that no longer receives security fixes.
- An admin panel at the default URL with no limit on login attempts.
What site owners can do themselves
Some risks can be reduced without any technical knowledge. Between audits, it's worth following a few simple rules:
- give every employee and contractor their own account and disable it as soon as the engagement ends;
- use a password manager and two-factor authentication for the admin panel, email, and hosting;
- don't install modules from untrusted sources, and don't ask developers to "just turn off updates";
- keep the domain and hosting registered to the company, not to an individual.
These habits don't replace a technical review, but they significantly reduce the chance of a problem caused by human error.
What affects the cost of an audit
- Site size and type: a site on a popular CMS is easier to review than a system with a lot of custom code.
- Audit depth: versions and settings only, or manual code review as well.
- The number of servers and services included in the scope.
- Amount of remediation: whether it's just module updates, or rewriting unsafe code and cleaning up after a breach.
FAQ
Will the audit affect how the site works? Usually not. We run checks carefully, and anything that could affect the site is done on a staging copy.
My site has already been hacked. What should I do? Don't delete anything yourself, and change the passwords for the admin panel and hosting. We'll help you find out how the breach happened, remove the malicious code, close the vulnerability, and restore the site from a clean backup.
How often should a site be updated? Critical security updates should be installed as soon as possible after release; the rest can follow a schedule. The exact cadence depends on your CMS and the number of modules.
Can you audit a site you didn't build? Yes — audits are often ordered precisely for sites inherited from other contractors.
Why Promodex
We've been building websites on a range of CMSs and frameworks since 2015, so we don't check security against someone else's template — we understand how the code works from the inside. The audit and fixes are done by a single in-house team, with no outsourcing, and you know in advance what we're doing and why. After the audit, we can stay on and keep your site updated.
