The article
The penetration test is over. You have a report with findings sorted by color, a client who wants proof they are closed, and a team busy shipping features. Cybersecurity remediation services exist for that list: someone fixes the findings in the code, the servers, the cloud and the settings, then tests again to prove they are closed.
I have been building software for 18 years, and my company, 26 Lines of Code, has delivered 150+ projects since 2017 with a team of 70+ specialists. Here is how we work through a findings list, a 30-60-90 day plan you can use with any team, and what "closed" should mean.
Cybersecurity remediation services: the short version
| What | How it works |
|---|---|
| What we fix | Vulnerable libraries and the code that uses them, holes in your app, server, device and cloud settings, old accounts and rights that are too broad |
| From which report | Any audit, penetration test or scan, ours or another company's |
| In what order | By risk and effort, the critical findings first, with updates on what is closed and what is next |
| Proof | Every fix is checked again, and you get the record your auditor or your client will ask for |
| Price | Estimated before work starts; the first call and the rough estimate are free |
Why findings stay open
A report usually lands with people who did not write the code. Many findings sit in the application itself: an outdated library, a missing check, a key left in the code. Good cybersecurity systems remediation services cover the code as well as the servers and the cloud around it: a firewall rule can hide a hole for a while, but only a change in the code closes it. Our developers patch the application, not only the server around it.
In October 2026 I read the five pages Google showed for this search. They cover patches, networks, plant control systems, compliance and cleaning up after a breach. None mentions changing an application's own code, and none says the fix gets tested again. Five pages are a small sample, but ask both questions before you hire anyone.
The worst first
We sort the findings by risk and effort, fix the critical ones first and keep you posted on what is closed and what is next. Risk is what a finding exposes and who can reach it: a hole that faces the internet outranks the same hole behind a VPN. Effort sets the order inside each level, so a one-line setting goes before a week of rework.
A 30-60-90 day plan for a findings list
The days are a template; the length of your list sets the real pace.
- Days 1-30, the doors. Critical and high findings that face the internet. Shared or leaked keys replaced, accounts of people who left closed, two-factor sign-in on every admin account. Where the real fix takes longer, a stopgap such as a firewall rule or a feature switched off, with an end date.
- Days 31-60, the code. Libraries updated together with the code that uses them, missing checks added, rights cut down to what each role needs.
- Days 61-90, the ground. Servers and cloud settings hardened, the low findings worth fixing, and every finding you decide not to fix written down with who decided and a date to look again.
Each fix is checked again as it closes, so on day 90 the list has three columns: closed with proof, accepted in writing, and planned.
What "closed" means
A finding is closed when three things are true: the fix is live, the check that found it has been repeated and finds nothing, and the record says what changed, when and how it was checked. Anything less is open, whatever the ticket says. That record is what your auditor or your client will ask for.
Treat each finding as a task, not a line in a PDF. In PBM Source, compliance software for pharmacy benefit managers from our portfolio, every new law lands on a dashboard as a task with a summary, a jurisdiction and a date, assigned with its documents in one place. A findings list deserves the same: an owner, a date and the evidence next to each item.
After the list is closed
Closed holes reopen when nobody watches: a library falls behind again, a new admin skips two-factor sign-in. Monitoring watches the logs and the alerts, and software maintenance keeps the libraries current. If the findings came from a breach rather than a test, start with incident response.
Send us your findings from any audit, penetration test or scan; no report yet means a penetration test comes first. We reply with how we would fix them and a rough estimate, free, and on weekdays from 9 am to 6 pm Miami time we answer new requests within 30 minutes. If you need an NDA, we sign it before you share details. More under cybersecurity.
