Playbook, developer tools company
An engineer has been handed a review and does not own the answers
The person pasting these questions did not write them. Their own security team produced a spreadsheet, the engineer who wants to adopt the tool has been told to complete it, and they are hunting for the published document that satisfies a row. Most rows have a public answer. A few need a signed agreement and a person. Knowing which category a row falls into is the useful thing an assistant can do here.
Why this is not the general answer
The handling pattern for security questionnaires holds across every trade. What follows is the part that does not.
- What a technical review actually asks about is narrower than it looks: whether there is an audit log, what it records, how long entries live and who can read them. General assurance about posture answers none of those four.
- The deployment model decides who owns half the answers, because on a self hosted install the controls are the customer's own, and saying so early saves a reviewer completing rows that do not apply to you at all.
- Reviewers now routinely ask about the composition of the software itself, the dependency inventory and how a release is signed, and that is either a published artefact or it does not exist.
- The test report and the certification letter sit behind an agreement, so the right answer to those rows is the route for requesting them rather than a summary of what they say.
How it arrives
- do you have an audit log and what does it record
- how long are administrative actions retained
- can we get your most recent penetration test report
- do you publish a dependency inventory with releases
- are release artefacts signed and how do we verify one
- who inside your company can read customer data
What has to be indexed for this to work
| The audit log specification, in five parts | Which events are recorded, what an entry contains, how long entries are kept, whether they can be exported and which plan the capability sits on. A product page saying audit logging is available answers none of the five and generates the same follow up every time. |
|---|---|
| A responsibility split by deployment model | A table of controls with a column saying whether each is yours or the customer's on a hosted install and on a self hosted one. It converts a long questionnaire into a short one, and it is the document reviewers actually thank you for. |
| Release integrity: signing, checksums and the dependency inventory | How an artefact is signed, where checksums are published, the verification steps a customer follows, and whether an inventory ships alongside. This is now an ordinary row, and an unanswerable one stalls an approval without anybody telling you. |
| An index of trust material, marking each item public or under agreement | Certifications, test summaries and architecture documents, each labelled with how it is obtained and the route. The categorisation saves more time than any individual document, because it tells the reviewer what to stop looking for. |
The reply
The audit log records the event types listed on that page, each entry carrying the actor, the time and the object affected, with entries retained for the published period and export available on the plans noted there [1]. If you are evaluating a self hosted deployment, several rows in a review like this are answered by your own infrastructure rather than by us, and the responsibility table sets out which are which [2]. Release artefacts are signed, and the verification steps and checksums are published with each release. The penetration test report goes out under an agreement rather than publicly, so leave your name, your work email and your organisation and the team will send you the route for requesting it.
It answers the audit log question in the shape a reviewer needs, event types, entry contents, retention and export, because a single word yes comes back with four follow ups attached. Pointing at the responsibility split early is worth more than any individual row. The report is refused by category rather than apologised for, and the handover offers a route rather than a promise.
Where it stops
The trigger. The reader asks for a report, certification or architecture document released only under an agreement, or asks something the published trust material does not cover.
That one is not published, it goes out under an agreement instead. Leave your name, your work email and your organisation, and the team will send the request route along with whatever can be shared straight away.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never assert a certification, an audit outcome or a compliance status that is not published in your own trust material.
- Never describe internal access controls, staff permissions or key handling beyond what a published document already states.
- Never say a control is in place on a self hosted deployment, because that install is operated by the customer and not by you.
- Never summarise the findings of a test report, however urgently a reviewer says they need it.
Questions
- Should it answer security questions at all?
- It should answer from published trust material and from nowhere else, which is a genuine service, because those rows have documented answers reviewers cannot find. Everything else becomes a routed request. The danger is not the questionnaire, it is improvising a reassuring sentence about a control.
- Can it complete a spreadsheet for us?
- No. It reads documents and writes nothing anywhere, so a completed questionnaire is always somebody's work. What it takes away is the traffic from rows already answered in public, which is most of the sheet.
- What is the highest value thing to publish here?
- The responsibility split by deployment model. It is short, it is unglamorous, and it deletes whole sections of a review for every self hosted evaluation that reaches you.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- Handling security questionnaires in generalA buyer-side question arriving in the wrong place. Answer only what you publish, and never let an assistant improvise a claim you then own.
- Access problems where half the accounts do not belong to anybodyMachine identities, organisation membership and credentials shown only once. Access questions where the actor is a process rather than a colleague.
- The word reset covers two things here and one of them cannot waitRotating a credential without dropping traffic, and the first move when a token turns up in a public commit. Neither is a password reset.
- Cancelling ends the commercial edition, not necessarily the softwareAnnual terms, a credential that stops authenticating on a date, and an open source core somebody keeps running. What can honestly be stated.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.