How to review documents with an external vendor without losing control

The last project I worked on had six phases and more than thirty documents.

Reports, annexes, findings spreadsheets, meeting minutes. Not one of those

documents lived in a single place. They lived in email threads, with names

like Characterization_Report_v1_1_rev_JA_final.docx, and the status of each

one lived in somebody's head.

This is not a personal tidiness problem. It is structural, and it shows up

every time documentation crosses the line between two companies: the vendor

produces, the client reviews, and nobody owns the whole process because each

side only sees its own half.

What actually breaks

When a cross-company review falls apart, it is almost never because somebody

failed to read the document. It is one of these four things:

Nobody knows which version is current. The vendor sent v2 on Tuesday,

somebody on the client side replied about v1 on Wednesday, and by Thursday

there are two parallel conversations about different texts. Email has no

concept of "the current version". It has a concept of "the latest message".

The document has a sender, not an owner. Those are different things. The

sender mailed the file; the owner answers for its content. When there are

only senders, a comment nobody picks up simply disappears — and resurfaces

three weeks later in a meeting.

The approval is not recorded anywhere. "I reviewed it, it's fine" said in

a meeting is not an approval. It is a memory. When you need to show that the

deliverable was accepted — in an audit, in a scope argument, at a phase

closeout — there is nothing to show.

The comments have nowhere to live. The security architect builds a

spreadsheet with findings on the annexes. The operations team writes its own

report on the main document. Two new files, each with its own context, that

exist because of a document but are not attached to it in any system. They

end up as attachments in separate threads.

Four rules that work

None of these rules require buying software. They require deciding something

and sticking to it.

1. One document, one named owner

Not "the security team": a person. The owner is not necessarily the writer;

the owner answers for the document's status and has to get it moving. If a

document has no name next to it, that document has nobody.

2. Status is written down, not remembered

A document is in draft, in review, approved or rejected. Four states are

enough, and the point is not the number: it is that status must be a fact you

can look up, not a conversation. The question "where is the characterization

report?" needs an answer that does not depend on finding the right person.

3. Approval leaves a trace: who, when, against which version

All three or it is worthless. Approving "the report" means nothing when there

are four versions of the report. What gets approved is version 3 of the

report, on October 14th, by a specific person. That is what you can show later

without reconstructing a story out of old email.

4. Whatever the document generates is stored next to the document

The findings spreadsheet, the response report, the minutes of the meeting

where it was discussed: all of that is part of that document's file, not loose

material. If it lives in a separate shared folder, six months from now nobody

will know it existed.

Why a shared folder is not enough

This is the fair objection: *a cloud folder with permissions already solves

this*. It does not, and the reason is precise. A shared folder solves

storage: where the file is, who can open it, which version is the latest.

It does not solve governance: who answers for it, what state it is in, who

approved it and against which version.

Those are two different problems and they get conflated constantly. It is why

projects with an immaculately organized folder still have exactly the same

arguments at phase closeout.

What I built out of this

I spent years on projects like that and ended up building Matrical to

solve precisely this: every document with an owner, a state and an approval

recorded against a specific version; reviews as rounds with their own history;

and the back-and-forth with the vendor — messages and files — stored next to

the document that caused it, not in an email thread.

You can start free with one project, no card required, and

pricing is per account rather than per user: adding the vendor as

a reviewer costs nothing extra.

But if you take only one thing from all this, take the cheapest one: next time

a deliverable lands in your inbox, before you open it, write down who answers

for it and what state it is in. That alone saves you half the arguments.