What we do with the findings
We take the list you were given and work through it. That means the code, and the servers and services around it, because where a finding shows up and where it gets fixed are not always the same place.
It makes no difference to us that somebody else wrote the list. The work gets the same treatment as anything else we build.
We don't ask you to take our word for a fix. Each one comes with a test that fails before the change and passes after it, so you can run it yourself. And if a fix has to reach into another part of the system, we tell you what it touched before it reaches your users.
What else a fix touches
Fixes break other things when nobody knew the two were connected. So before we change anything, we read the system the way it actually runs: what depends on what, and which parts are shared by more than one feature.
Then we write down what it means for those parts to be working properly, and we cover them with tests before we touch them. That is how we can tell you in advance what a fix will affect. If it stays in one place, we can show you why. If it doesn't, you hear that before we start rather than after something stops working.
We don't grade our own work
We don't run penetration tests, and we don't check our own fixes. The retest stays with the firm that wrote your findings, on their schedule and their judgment. That's as it should be. A company that fixes the problems and then marks its own work leaves you no way to tell careful work from a confident report.
So we won't promise you a passing retest. Nobody doing the fixing is in a position to promise that. What you will get from us, before the work starts, is which findings we can close, which ones need a decision from you first, and what we would want to change beyond what's on the list.
The report goes stale on its own
A report is a photograph of one day. The code your application depends on keeps getting new versions, and some of those versions exist because somebody found a problem in the last one. Anything you build after the report was written has never been looked at with any of this in mind. So a system that closes every finding this month is a different system by the time anyone tests it again. The next test starts wherever it has drifted to, not from the clean state you paid to reach.
If closing the findings were the end of it, we would say so and leave it there. It isn't the end of it, and the difference is whether somebody is watching the system in the months after.
Ongoing stewardship
From $2,000/month
Continuing care for a system in production, month to month.
Stewardship means somebody keeps looking after the system once the fixes are done. We watch it, we keep the code it depends on up to date so it doesn't turn into next year's findings, and we answer when something breaks. You also keep access to the person who already knows why your system works the way it does. When something goes wrong, the work starts right away, instead of starting with finding somebody to take it on.
None of that depends on what your report says, which is why we can describe it before we've seen it. What it costs depends on the system itself, so that part comes after we've looked.
We keep your system doing what it does today. Changing what it does is a project, quoted separately.