The request arrives in a diligence list or an audit scope as one bland line: evidence of documented processes and controls. The usual response is to assemble everything that exists into a shared folder and hope the volume reads as maturity.
It does not, because volume is not what is being tested.
What the question is actually asking
An investor asking about documented operations is asking one thing: if a key person leaves, does the business keep working? They are pricing key-person risk. A folder of documents nobody follows does not reduce that risk and an experienced diligence team knows it.
An auditor is asking something adjacent but stricter: does the control you described to me actually operate, consistently, and can you show me that it did? They care much less about the document existing and much more about evidence that it was followed.
Both of those are about operation, not authorship. That changes what you should prepare.
Prioritise the processes that touch money, data, or access
You cannot document everything before a diligence deadline, and you do not need to. Concentrate on the areas anyone assessing you will actually probe.
- Anything that moves money. Payment approval, expense authorisation, payroll, refunds, and specifically who can approve what without a second pair of eyes.
- Anything that grants or removes access. How someone gets an account on day one and, far more importantly, how it is removed on their last day. Offboarding is where most teams fail this question.
- Anything touching customer data. Who can access it, how a deletion or export request is handled, what happens in a breach.
- Revenue recognition and billing. How a signed contract becomes an invoice and how exceptions are handled.
- Incident response. What happens when something breaks, who is told, and how it gets recorded afterwards.
Documentation without evidence of use is worth very little
This is the part teams underestimate. A procedure that says "invoices over 10,000 require director approval" is a claim. What satisfies an auditor is being able to show that the last twenty such invoices actually had one.
So when you document a control, think about what leaves a trace:
- Who approved this, and is that recorded somewhere durable rather than in a chat message?
- When was this procedure last reviewed, and by whom?
- What version was in force at the time of the transaction being examined?
- Can you show that the people expected to follow it have read the current version?
This is why version history and an approval trail matter more than formatting. A document you can prove was approved on a date, by a named reviewer, and has been reviewed since, answers a question that a nicer PDF cannot.
Do not write it for the auditor
There is a strong temptation to write an idealised version of the process, the one with all the controls, and present that. Do not.
The risk is not being caught in a lie, though that happens. The risk is that you now have two processes: the documented one and the real one, and every future review measures you against a standard you never actually operated. Auditors find that gap by asking the person who does the work, and it turns a documentation finding into a credibility problem.
Document what you actually do. If a control is missing, note it as a known gap with a remediation date. A specific, acknowledged gap reads far better than a discovered discrepancy.
Be honest about what tooling does and does not give you
Documentation tools, including ours, help you write procedures, keep them versioned, route changes through an approver, and re-verify them on a schedule. That is genuinely a large part of what a diligence request about documented processes is asking for.
What they do not give you is a compliance certification. If your requirement is a SOC 2 report, ISO 27001, HIPAA, or enforced single sign-on across your stack, that is a different category of product and a different project. Sendabrief has no SOC 2 attestation and no SSO, and if either is a hard requirement you should discount it for that use case.
The useful framing: documentation tooling helps you answer "do you have a documented process for this and can you show it was followed". It does not answer "are you certified".
A pragmatic order of work
- List the processes touching money, access, and customer data. Usually a dozen or fewer.
- For each, write down what actually happens today, including who approves and where that approval is recorded.
- Mark every place where the real process has no control, and give each a remediation owner and date.
- Get each procedure reviewed by someone who is not its author, and keep that record.
- Set a review cadence per procedure so a reviewer date is never more than a quarter old at the point someone asks.
- Only then worry about presentation.
Where Sendabrief helps
The reason this exercise stalls is almost never that nobody understands the process. It is that writing it down is slow and the people who know it are the busiest. So: have the person who performs the approval walk through it on a recording, or explain it out loud for two minutes, and get a structured procedure back rather than a blank page.
The parts that matter for diligence specifically are the governance layer. Every change goes through an approver who is not the author, version history shows what was in force when, and scheduled review cycles mean a procedure's last-reviewed date is a real date rather than whenever someone last happened to look at it.