Before a set of sensitive files leaves the company, who is allowed to approve the send? One person, or two different people who both have to sign the same send before it goes out? One person prepares the files and asks for the send. A second person reviews that request and accepts the risk. Both names stay on the record for that send, and you can export proof of both decisions later.
A share link that goes out with no approval at all is the weakest case. One named person clicking approve is stronger: the log shows who let the files leave. Banks and payment teams already treat one approval as too thin for moving money or granting admin rights. File sharing often still stops at that one click. Reviews keep finding the same hole. A contractor file set, a medical-record export, or files an AI agent assembled for a partner left on one person's say-so, with nobody else required to look at that same send.
The decision that actually matters
Product pages talk about approval steps, links that expire, and guest accounts. The question that shows up in control reviews, customer security questionnaires, and after an incident is narrower:
When a person, a guest, or a job an AI agent prepared sends sensitive files outside the company, do two different people have to approve that same send, with a new review if the files or the destination change, and with both decisions on one timeline? Or can one authorized person finish the send after a single click or a single ticket stamp?
"Managers approve external shares" and "we review it in Slack" are processes. You still need proof that two different accounts were tied to that send before the files left, and that a one-person path was blocked for that kind of content.
What most teams still do
Two-person sign-off is normal for money movement. For files leaving the company, it usually falls back to how people already collaborate:
- One security or operations owner can approve and send. The same person requests the share and clears it under one login.
- The second look lives in a ticket comment or a chat thread. The file system records one send event and one person. Months later, reviewers rebuild the second look from other tools.
- Change tickets support several approval steps. The share itself still goes live when the first allowed role says yes.
- An AI agent assembles the files and asks to send them under a service account. One human approves. Nobody else checks the destination, a hash of the files, or the reason for the send before it goes live.
- A sensitivity label picks one approver from a pool. That person may be the one who built the file set, or a peer who never sees the files and the destination together.
- Emergency and after-hours paths drop to one person. When an auditor asks which sends skipped the second review, there is no single record of those exceptions.
- The export lists approve and send for one person. The requester, the reviewer, the rule that they must be different people, and the skip or deny events are missing, or they sit in ticket and email logs that cannot be joined back to the files.
That holds until a customer asks who else reviewed the claims files, a regulator asks whether medical records could leave on one person's authority, or an incident team needs to show that files an agent prepared could not leave without two people accepting the risk. At that point, two-person sign-off is the control that decides whether the send was a solo action or a two-person event.
What two-person sign-off on the send means
Treat a high-risk send as a record that cannot go live, outside the company or across a company boundary, until two different people finish ordered roles. The maker prepares the files and requests the send. The checker reviews that request and accepts the risk. A setup that still holds up later usually has these properties:
- Two people on one send record. The record names the files or folder, the kind of destination, the rule that applied, how long the share lasts, the maker, and the checker. The checker has to be a different person from the maker. A shared mailbox or a "security team" alias does not count as two people.
- The roles are enforced when the share goes live. Preparing or requesting the send is the maker's step. Allowing the files to leave is the checker's step. The system blocks the same person, and the same agent account, from completing both steps on that send.
- A rule decides when two people are required. The rule can key off a sensitivity label, a destination outside the company or in another entity, files an agent prepared, a contractor recipient, a regulated data type, or file size and type. Everyday shares can keep a single approval. High-risk sends stay blocked until both decisions are in.
- Each decision applies to the files as they stand. Both people review the current files (or a hash of them), the destination, the reason, and who is involved. If the files change, the scope grows, or the destination changes after either step, the chain is thrown out or both steps run again.
- People and agents are named separately. An agent can prepare the files and request the send while two people review it. A person can request it and another person can approve it, with the agent listed as the one who prepared the files. Each name appears on the export, separate from a login the agent borrowed.
- Skips, timeouts, and emergency overrides are recorded. A bypass, an escalation, a timeout, or an emergency one-person send writes an event with a reason and the backup control that applied, on the same timeline as the files.
- The audit is one timeline. Request, first decision, second decision, deny, timeout, share going live, open, download, revoke, and expiry sit on one export. Nobody has to stitch admin consoles and chat history together by hand.
A multi-step ticket can be closed and still leave the share itself on one person's authority. Two-person sign-off on the send record is what an auditor can still read eighteen months later.
One approval and two approvals are different controls
One named person accepting the risk before files leave is a real control. Two-person sign-off adds a separation rule on top of it. They answer different questions, so they belong on a ladder.
- One approval answers: did a person allow this kind of send before the share went live?
- Two-person sign-off answers: did two different people, or a maker and a checker where an agent may be the maker, approve that same send before it went live?
Calling both of those "we have approvals" leaves high-risk sends underspecified. Requiring two people on every casual share adds delay and blocks little risk. The design choice is which sends need one approval, which need a maker and a checker, and how both show up as events on the send record itself.
Questions to ask in a review
Use these in a vendor review, an internal platform review, or a build gate. Score what the product can show, not what the slides say.
- Can sensitive files going outside the company, or across a company boundary, go live on one person's authority, or does a rule require two different people before the share opens?
- Are the requester and the reviewer stored as separate identities on the send record, with a block so the same person cannot do both?
- Which labels, destinations, people, and automation cases require two people, and which keep a single approval? Can those rules differ for employees, contractors, guests, and agents?
- If the files, the destination, or the reason change after the first decision, do both steps run again, is the chain thrown out, or does the share continue on the old approval?
- Can an agent request the send under its own identity while two people complete the review, or a person request it and another person approve it, with every name on one export for those files?
- Do denies, timeouts, escalations, and emergency one-person sends write events with reason codes, or do they leave a gap you can only fill from chat history?
- After both people have approved and the share is live, what does revoke do? Does it kill the share, wait for a cache to expire, or rotate a password and stop there?
- Can you export one timeline for those files, from the request through both decisions, the share going live, opens, and revoke, without joining ticket, email, and file consoles by hand?
- In a SOC 2, HIPAA, or CMMC review, which records prove two different people approved the send, and which only prove that an approval workflow exists somewhere?
- Do one-off sensitive shares and planned partner transfers use the same two-person rules?
A strong answer shows fields on the send record, a sample export with both names, and the rule that decides when two people are required. A weak answer points at a multi-step ticket that never ties two people to the share.
Closing
Two-person sign-off on files leaving the company means the requester and the reviewer are different people on the same send record, a rule decides which sends need both decisions, and both steps stay on the record next to the share going live, opens, and revoke. Teams that write that down early give security, compliance, and operations the same definition of done for partner file sets and for files an agent prepared. Put the second person on the send. Keep the proof exportable. The next review, or the next incident, will ask for the second signature you can show.