You hire a partner to run your cloud environment because your team cannot be everywhere at once. So the partner gets keys. They can grant access, revoke it, change a policy, pull a report, touch the systems that hold your data. That is the deal, and it is a reasonable one. You traded some direct control for the time and the coverage you needed back.
Then a question arrives that you cannot wave off. Your auditor, or your biggest customer's security team, asks who changed a permission three months ago. You know your own people did not do it. Which means your partner did. And now you are sitting with an uncomfortable realization: you handed someone the keys to your house, and you have no idea what they did while they were inside. You can ask them. They will probably tell you. But "they told me" is not a record, and you carry the mandate to produce records.
Here is the question worth sitting with before that day comes. When the people running your environment make a change, is there a trail you control, or only their word for it?
The keys come with a quiet asymmetry
Most managed service arrangements log your side of the story well enough. You filed a request, you approved an access grant, you replied on a thread. That part gets captured because it is your activity in your account.
The provider's own actions are where it goes dark. A great deal of the real work happens on the provider's side: the operator who revokes a departed contractor's access in Entra, the engineer who tightens a Conditional Access policy, the teammate who exports a report to answer your question. Those are the changes that move your security posture. Those are exactly the changes an auditor asks about. And in a lot of arrangements, they live in the provider's internal tooling, a ticket queue you cannot see, or nowhere at all.
That asymmetry is not malicious. It is just how the tooling usually gets built: instrument the customer, trust the operator. The result is a record with a hole in it, shaped precisely like the most powerful person in the room.
Accountability has to point both ways
A control that only watches one side is not a control; it is a courtesy. If the trail records what your team did but not what your provider did, the trail cannot answer the one question that matters most when the keys are shared.
So we built the activity log to record both sides, with no exception for ourselves. When one of our operators acts in your account, that action writes to the same log you read, with the operator's name and role attached, marked clearly as our side, distinct from yours. The change to revoke a contractor's access sits next to the request that asked for it. You do not take our word for what happened. You read it.
The point of provider accountability logging is plain: the partner holding the keys should be the most documented actor in the account, not the least.
This is the part people mean when they say a partner should be on the record. We are not asking for trust as a feeling. We are handing you the evidence and letting the record earn it.
Why this is operational work, not a report
There is a tempting shortcut here, which is to have the provider write you a monthly summary of what they did. A tidy document, delivered after the fact. It feels like accountability. It is not.
A summary is assembled by the same party it is meant to hold accountable, after the work is done, from memory or a private queue you cannot inspect. SOC 2 is paperwork with consequences, and a reviewer reading a Type II report is testing whether a control operated across the whole period, not whether someone wrote a nice recap at the end. The American Institute of Certified Public Accountants describes a Type II report as covering the operating effectiveness of controls over a stated period of time (see the AICPA SOC 2 overview). A recap written in arrears does not show that.
A log written as the work happens does. When our action records itself at the moment we take it, the evidence is a byproduct of running the environment properly, not a separate deliverable we produce when you ask. You filter the log to the period in question, read down a feed where both sides are visible, and export it. The proof was already there because the work wrote it down.
Where we draw the honest line
A few things sit outside this on purpose, and you should know them before you lean on the log. Our internal teammate notes are not in it; the action a note led to is logged, but the working note itself is not. A change someone makes directly inside a vendor console, without coming through our process, leaves no trace we can invent after the fact. And the log covers the work that flows through us, not every click in every system you own.
That boundary is the point, not a gap we are hiding. A log that claimed to see everything, including what it cannot observe, would be a record you could not trust, and an untrustworthy record fails the moment an assessor leans on it. We would rather show you a smaller trail that is true than a complete one that is fiction. For how the day-to-day record gets kept, the portal's organization activity log article walks through what lands in it and how to export it.
Back to the keys
Walk back to the day the question lands and you realize your own people did not make the change. In the usual arrangement, you call your provider and wait for an answer you cannot independently check. In one built on both-sides logging, you open the log, filter to the period, and read what we did, in our name, with a timestamp, right next to the request that prompted it. There is nothing to reconstruct and no word to take, because the people holding the keys wrote down what they did while they were inside.
That is the trade we think a partner owes you in exchange for the keys. A promise to behave is cheap. A record that proves it is the thing worth having. So the question is not whether you trust your provider. It is whether your provider gave you anything to check. Does yours?