A company lands a bigger client — one that bills more, serves more people, or works in a more regulated industry — and the contract arrives with a security questionnaire attached: eighty questions about how the vendor's IT is run. How backup works, who has access to what, whether access is logged, who tells whom if something goes wrong. The reply is usually due in a week.
According to the executive summary of Verizon's annual data breach report for 2026, breaches involving a third party grew 60% in a year and now account for 48% of everything recorded — nearly half. That is why more and more large companies treat their own vendors, including their IT provider, as part of the security risk they need to manage, not as an outsourced item nobody tracks.
For the company on the receiving end, the problem is rarely the question itself. It is not having the answer ready: nobody knows how long a backup takes to restore, there is no list of who can access what, and nobody can say who calls whom if a system goes down. Whoever answers late does not just lose one contract — they lose the chance to grow with the right client.
The Questionnaire That Decides The Contract
The form usually covers the same ground: how and where data is stored, who has access to each system, whether that access is logged, how long it takes the business to get back up after a serious problem, whether security updates are current, and who gets notified — in what order — if something breaks. It is also common to ask whether the company outsources part of the work, and to whom.
The reasoning behind this scrutiny sits inside Brazil's data protection law, the LGPD. The law separates whoever decides what to do with the data — the controller, usually the client itself — from whoever processes that data on someone else's behalf — the processor, the role the vendor's IT provider plays. According to Brazil's data protection authority, the controller is the one legally required to report a security incident, but the processor must notify without delay and hand over everything needed to do so. In practice: if the incident happened on the vendor's computer, server or network, it is the client who answers for it under the law — which is exactly why the client wants to know, before signing, whether that setup is actually looked after.
This is not only about large companies. A two-shift factory supplying a retail chain, an accounting office serving a lender, a clinic working for a health plan — all of them sit inside someone bigger's supply chain, and someone bigger is watching that chain closely. What changes is the size of who is asking; the question is the same.
Companies that answer poorly are rarely told why. The usual outcome is silence: the proposal goes cold, the contract goes to whoever answered with confidence, and the company never finds out that an IT questionnaire decided the deal.
Why The Usual Approach Falls Short
The usual way of running IT at a small or mid-size company is to call someone when it breaks, trust a backup nobody has tested, and let system access pile up as staff come and go — with nobody removing what former employees no longer need.
That approach works fine until someone asks. There is no written list of who can access what because nobody ever needed one. Nobody tested the backup because it "always worked." There is no plan for what to do if a system is breached, because that never happened — until it does.
The issue is not carelessness. It is the absence of a record. The company may be backing up properly, may have strong passwords, may even run good antivirus protection — but if none of it is written down anywhere, the answer to the questionnaire becomes "I think so," and "I think so" does not close a contract.
Buying another security tool without documenting what it does is another version of the same problem: the client auditing you is not asking which product you use, they are asking what that product guarantees — and a tool with no process around it guarantees nothing you can put in writing. It is a pattern Skills IT sees repeat itself: tool purchased, process never written down, questionnaire failed.
What Has to Be in Place
Answering the questionnaire with confidence does not depend on buying something new. It depends on the company's IT having a few basic mechanisms in writing.
An inventory of systems and equipment. Knowing which computers, servers and systems the company runs — and who is responsible for each one — is the foundation of any answer. Without it, every question on the form turns into a last-minute investigation.
A record of who has access to what. A directory of users and passwords showing who can reach each system, updated whenever someone leaves the company, answers a good chunk of a security questionnaire on its own.
Backup tested, with a known recovery time. Having a copy is not enough: the company needs to know, through a real drill, how long it takes to get back up after losing a system.
A written incident response plan. Who notifies whom, in what order, and what happens first if a computer is infected or an account is compromised — written down, not kept in one person's head.
Security updates kept current. An outdated system is the most common way in, and "whenever we get to it" does not satisfy an auditor.
A single point of responsibility for IT. When the client asks "who handles this at your company," the right answer is a name or a team — not a list of four different vendors, each covering a piece.
This is how Skills IT works: with a documented inventory and access log, backup tested through real drills, and every support ticket logged with its cause and resolution — the basics that any security questionnaire asks to see.
What The Company Gains
The benefit of having those answers ready does not show up only on questionnaire day. It shows up beforehand, in a proposal that closes faster because it does not need a second round of follow-up questions. And it shows up afterward, in a team that does not drop the day's work to scramble through a last-minute audit.
There is a direct financial gain here. Every week a contract stalls over an unanswered question is revenue that does not come in. And every time the company answers with confidence, it qualifies for the next client of the same size — the kind of client that, more often than not, also audits.
There is also a gain that never shows up as a number: deciding with information. When the owner knows, without asking anyone, how long it takes to recover a system or who has access to the finance files, they stop depending on one person's memory — and start deciding based on what is written down.
Questions to Bring to the Next Meeting
Before the next questionnaire lands, it is worth asking what the company would answer today:
- Does anyone know, right now, how long it takes to restore a backup after a serious problem? If the answer is "not sure" or "probably fast," that is the first question on the form that already fails.
- Is there a list of who has access to each system in the company? Without that list, every access-control question turns into a guess.
- If a system went down today, is it written down who notifies whom, and in what order? Figuring that out in the moment costs time a client running an audit will not forgive.
- Can the company list the equipment and systems it runs without relying on memory? An outdated inventory is nearly as bad as no inventory at all.
- Does whoever signs the security questionnaire actually know what they are promising? Answering "yes" to a question nobody confirmed is the risk that surfaces later, when the client finds out on their own.
