The email lands on a Wednesday. A prospect you have been courting for a quarter, the kind of logo that changes your next board meeting, wants to move forward. Attached is their vendor security review. 40 questions about access control, change management, incident response, and the one line that makes your stomach drop: "Please provide your most recent SOC 2 report and supporting evidence."
You are the chief operating officer. You do not write policies for a living, and you certainly do not enjoy spelunking through last year's shared drive looking for the access control document that may or may not still be accurate. So you start the familiar scramble. Which folder has the current incident response policy? Who has the spreadsheet of who-did-what? Did anyone write down when you offboarded that contractor in March?
Here is the quiet truth the scramble reveals: the evidence either exists as a byproduct of how you run, or it does not exist at all. You cannot manufacture six months of clean records the week an auditor asks. What you can do is run the environment so the proof is already sitting there, current and findable, the moment someone asks to see it. That is what the policy library and the activity log are for.
Two surfaces do most of the work
When an auditor or a buyer wants proof, they are asking two questions. What are your rules, and can you show they were followed? Most companies answer the first with a stale PDF and the second with a frantic export from five different consoles. The portal answers both from one place.
The policy library holds the documents Cloud Sentry maintains on your behalf: the information security policies, the standard operating procedures, the onboarding and joiner / mover / leaver runbooks specific to your environment. The activity log is the chronological record of meaningful account actions, both yours and ours, with a badge on each entry showing which side took it.
One surface says what you do. The other shows you did it. Together they are the difference between an evidence request that takes an afternoon and one that eats a week.
A policy library that is current on purpose
A policy is worthless to an auditor if nobody can prove it is the version you follow in practice. In the reviews we run, the recurring finding is rarely a missing policy; it is a policy that says one thing while the environment does another.
The library is built to close that gap:
- Every document carries a Last updated stamp at the top, so you and the auditor can see at a glance how fresh it is.
- Each document is owned by a Cloud Sentry teammate who reviews it on a cadence, quarterly for active policies and annually for everything else, so the version you open is always the current approved one.
- The full text renders in the browser with a table of contents, no PDF download wall, and a full-text search across titles, headings, and body so the reviewer finds the clause they want in seconds.
When the environment changes (a new SaaS rollout, a new compliance scope, an org shift), the policy changes with it, because the team running the environment is the team maintaining the document. The proof and the work are the same thread.
An activity log built to be read by a stranger
A buyer's reviewer does not trust your word, and they should not have to. They want a record. The activity log is that record, and it is designed to be legible to someone who has never seen your account.
It captures the events that matter for accountability and skips the noise. Members invited, accepted, role changed, or removed. Access granted or revoked on your behalf. A policy refreshed. A primary contact changed. Routine traffic like reading a document does not clutter it. Each row shows the source, the actor, a plain-language action label, and a UTC timestamp shown in your local time. Click any row and it expands to the before and after values of the change.
SOC 2 is paperwork with consequences. The consequence of running the environment properly is that the paperwork writes itself.
Say a reviewer at Northwind Logistics asks how you handle offboarding. You filter the log to access changes, click Export CSV, and hand them a file with stable column names suitable for evidence. The export itself gets logged, so the trail of who pulled what stays intact. That is not a feature you turned on for the audit. It is a feature you have been quietly using all along.
Where the seams usually open
Honesty matters more than polish here, so two limits are worth naming. The activity log records actions that flow through Cloud Sentry. Changes someone makes directly inside a vendor admin console, without going through us, are not in it. If you need a cross-system view, we can assemble one as a one-off, but it is not automatic. And the library only shows policies for engagements that include managed compliance; if that is not your scope, the link does not appear. We would rather tell you where the edge is than let you discover it mid-audit.
The audit is just Wednesday, written down
Walk back to that Wednesday email. With the library and the log, the 40-question review stops being a scramble and becomes a retrieval. The access control policy is current because someone owns it. The offboarding question answers itself from a filtered export. The contractor you removed in March is a logged action with a timestamp, not a memory you are trying to reconstruct.
That is the whole idea behind running compliance as a daily operating habit, not an annual event. Evidence is not something you build for the auditor. It is the residue of doing the work in the open, every day, in one place. For the step-by-step version, the policies and procedures and activity log articles in the portal walk through each surface.
So when the next vendor review lands, ask yourself: are you about to assemble your evidence, or simply hand over what was already there?


