How to answer a security questionnaire, one question at a time.

Policies say quarterly. The reviewer is asking about the person who left in March, and periodic review is the wrong instrument for finding them.

A product question wearing a security costume, and the best example of a documented "no" being a better answer than a hedged yes.

The strongest version of this answer is not a time. It is a single action that covers everything, plus a list of what it does not.

The honest small-company answer is rarely a clean yes, and the answer that names its exceptions is stronger than the one that does not.

The gap here is almost always between "enabled" and "enforced", and between staff logins and the two or three accounts that could not take a second factor.

One of the few questions where the modern answer looks weaker than the old one and is in fact much stronger.

Answering yes to be agreeable grants a contractual right to send an assessor. Answering no with nothing offered instead leaves a gap in the reviewer's file. The useful answer is no, and here is what you get.

One of the few questions where the answer is usually no, and where no is a perfectly good answer.

If you have one, the cover page answers this question. The mistakes are all in the details it also contains: the type, the criteria, and the dates.

One of the few questions where most small companies genuinely have nothing, and where inventing a scheme is worse than saying so.

The fastest-growing question on vendor questionnaires, and the one where a careless yes is hardest to walk back.

Usually answered from the wrong seat. As a processor you are not meeting these requests, you are helping the controller meet theirs, and saying which one you are is most of the answer.

Where the servers are is only half of it. Who can reach the data, from which country, is the other half.

Logical separation is the true answer for nearly every SaaS, and also what somebody says when they have not thought about it. The difference is whether you can say how the boundary is enforced and tested.

The number is easy. What separates a good answer from one that unravels is whether it accounts for backups, logs and every other place a copy came to rest.

The database is the easy half. A reviewer at an EU company is asking about every sub-processor and about who can read a record from where.

The question moved on from antivirus. It is now about encryption, updates, and whether you can take a device away.

The question is about custody, not encryption. Answering "yes, AES-256" answers a different question and a reviewer will notice.

The question is about the credentials your software runs on, not the password manager the team uses. Rotation is the part most likely to be aspirational, and the follow-up is always the date of the last one.

One of the most common questions on any questionnaire, and one of the most commonly over-answered: most teams encrypt the database and forget the backups.

Easy to answer yes to and easy to check from the outside, which makes it one of the few questions where a wrong answer is found rather than believed.

At fifteen people this is not a change advisory board. It is whether your pipeline records who changed what.

Reviewers are testing one thing: what prevents an unreviewed change from reaching your customers' data.

Most answers describe authentication and stop. The question a reviewer is really asking is what stops one customer's token reading another customer's data.

The question FillTrust most often leaves deliberately blank. No security document contains the answer, and guessing a coverage limit is a representation you cannot support.

The most enterprise-shaped question on the questionnaire, and the one small teams most often answer with an aspiration.

Two questions in one, and the second half, the notification window, is the one with contractual teeth. It comes from your DPA, not from GDPR.

The dangerous answer is not yes. It is a confident no from a company with no logging, which is a claim about something it has no way of knowing.

The one answer that must match your contract word for word, because the contract is what a court reads.

Almost always a yes you inherit from your cloud provider. The part that is actually yours is the application layer, and that is the part reviewers probe.

You probably have three inventories already and have never called them that.

Half the answer belongs to your cloud provider, and the half that matters is yours. Naming the boundary is more useful than describing either side.

You do not run a data centre. Saying so, and naming who does, is the complete answer.

This one is a product question, not a security question, and the honest answer for most young products is no with an offer attached.

Two questions in one: what you record, and what happens when something in the record is worth waking up for.

One of the few questions answered from an HR document rather than a security one, which is exactly why it is often answered from memory.

The contractor is why this is being asked. "All employees sign an NDA" answers precisely the half of the question nobody was worried about.

An easy yes for most teams, and one of the few questions where the follow-up is a date rather than a document.

The answer is almost always no, and the mistake is a yes borrowed from a cloud provider. It is a status on a public list, so it is the easiest claim in the file to check.

Most SaaS companies answering this have no cardholder data at all, and say so badly. The strong answer is not yes or no, it is why the question does not apply.

Under Article 28(3) the customer cannot use you without this contract, so the question is not really a question. What varies is whose paper it is signed on.

The most-asked question in our corpus that no security document can answer, and one many vendors do not realise is coming until a university asks it.

Usually the controller's obligation, not yours. Saying so, and then supplying what theirs needs, is a better answer than either yes or no.

The easiest row on the questionnaire, and one people still lose points on, because the notice is public and gets read against everything else you claimed.

This is a contract question wearing a compliance question's clothes. The reviewer wants to know whether you will take on Business Associate liability, and no amount of security posture answers it.

Everybody takes backups. This question is about the last time one was proved to work.

Two numbers carry this answer, RTO and RPO, and they are the two a reviewer can hold you to during a real outage. Do not publish ones you have not measured.

Two numbers with no scenario attached mean nothing, and a reviewer who has to guess will assume the flattering reading and hold you to it.

A number with no measurement behind it is trivially checkable, against a status page and against the reviewer's memory of your last outage.

The question your customer is really asking is whether their data can reach somewhere they have not been told about.

Usually a yes waiting to be written down: if your builds are reproducible and your dependencies are scanned, you have the inventory and not the document.

The list is easy. What reviewers actually check is whether the unglamorous ones are on it: the error tracker, the support desk, the AI provider.

"We will notify you" and "we will notify you thirty days before" are different commitments, and this question is asking for the second.

Very few small companies run a bounty. Almost all of them should have the one-page policy, and it takes an afternoon.

This is the question FillTrust most often grades as inferred rather than confirmed, because policies state a cadence and cadences are not evidence that a test happened.

The question is not whether you patch. It is whether you can name the window and show that you meet it.