A questionnaire arrived. It came from a customer’s compliance team, a partner’s vendor review, an auditor, or your insurer. It asks about encryption, access logs, patching schedules, data retention, who can see what.
You read it and realize that for a meaningful number of the questions, you genuinely do not know the answer. Nobody at your company does.
That is a normal position for a business running software built years ago by someone who has since moved on. It is also solvable, and the path is more procedural than dramatic.
What they are actually asking
Compliance questionnaires look intimidating because they are written in regulatory language. Underneath, most of them are asking four questions in different ways.
What sensitive data do you hold, and where is it? Not in general terms — specifically. Which system, which database, in which country, and is there a copy anywhere else, such as an old backup or a test copy of your site.
Who can get to it? How many people have access, how is access granted and removed, is there a record of who looked at what. For health information under HIPAA this is a central concern; the requirement to log access is one of the most commonly missed items in older systems.
Is the software maintained? Do you install security patches, on what schedule, are you running versions that still receive them. This is where systems built years ago and left alone tend to fail, and it is the question that turns a compliance review into a technical project.
What happens when something goes wrong? Do you have a written procedure for a breach, do you know within what timeframe you must notify people, have you ever tested restoring from a backup.
Notice that only one of the four is about technology in a deep sense. The rest are about knowing your own systems and having records. That is good news, because facts are cheaper to establish than architecture is to change.
Where older systems typically fail
From doing this work repeatedly, the gaps cluster:
- Unsupported software. The single most common finding. If you are running a version that stopped receiving security fixes, you cannot truthfully claim your systems are patched, and most frameworks treat this as a direct finding rather than a judgment call.
- No access logging. The system knows who logged in, but not who viewed which record. Under HIPAA that is a specific requirement, not a nice-to-have.
- Sensitive data in unexpected places. Old backups on a desktop machine. A test copy of the live site, with real customer data in it, publicly reachable. Exported spreadsheets from three years ago sitting in shared storage. This is usually the most uncomfortable finding and the most common.
- Shared accounts. Several staff using one login means you cannot answer who did what, which undermines every access-related answer.
- Card details passing through your server. Many owners believe their payment provider handles everything, when in fact card data touches their system in transit. That materially changes your PCI obligations and is worth establishing precisely.
- No tested restore. Backups exist. Nobody has ever restored one. Under questioning that becomes “we believe we have backups,” which is not an answer.
How to answer the questionnaire in front of you
You do not need everything fixed to respond well. Three rules:
Never state something you have not verified. A confident wrong answer is much worse than an honest gap. It converts a technical shortfall into a credibility problem, and in a contractual setting it can be worse than that.
“We are establishing this, with a date” is a legitimate answer. Reviewers see it regularly. What they are assessing is whether you manage your systems deliberately. A specific plan with a date reads as control; vagueness reads as absence of control.
Answer the facts you do have precisely. Partial precision builds more confidence than uniform generality.
Getting the facts
Two steps, and the first one is free.
Ask your hosting company and your developer for one date each: when the versions you are running stop receiving security fixes. That answers the patching question with something checkable rather than a reassurance, and both answers fit in an email you can keep for the next questionnaire.
The second step is someone reading the system properly: what data is held and where, who can reach it, what is logged, what versions everything runs, where copies exist. Five business days, and what comes out is a written document in plain language mapping the actual state of your systems.
That document is the thing you have been missing. It is what you answer the questionnaire from, what you hand to a compliance consultant so they are not guessing, and what you give to any developer who works on this next. You own it outright.
Ordering the work afterward
Once you know the gaps, they get ranked by two things: how much risk each one carries and how long each takes to close. That ordering matters, because some items are days and some are months, and a questionnaire response is far stronger when it shows the high-risk items closed first.
In most cases the sequence is: remove sensitive data from places it should not be, fix access and shared accounts, get onto supported software versions, add the logging that is missing, then keep it maintained so this does not silently return in three years.
What it costs
The audit is $2,400, fixed, five business days. Making a system safe to touch — real backups, alarms, a test copy — starts at $6,000. Ongoing monthly maintenance covers the patching schedule you will need to be able to claim. Everything is priced here.
One honest limit: we are engineers, not your compliance advisor. We establish what is true about your systems and we fix what is broken. Whether that satisfies a specific regulation for your specific business is a question for someone qualified to answer it — and they will do a better job with our document in front of them than without it.