The folder nobody opened until the auditor asked
An auditor sends the email every operations director knows by heart. Please share your current information security policy, your access control procedure, and your incident response plan. You go looking. The policies are in a shared drive somewhere, in a folder created two reorganizations ago by a person who has since left. You find three files named some variation of "final." One of them has a date in the footer. None of them match how the team works now.
So you spend an afternoon you did not have reconstructing which version is real, whether it reflects how the team works today, and who approved it. The document existed the whole time. Finding the right one, and trusting that it was right, was the part that ate the day.
This is the quiet tax on compliance work: the documents are written once and then left to rot in a folder, so every audit becomes an archaeology project. The fix is not writing better policies. It is keeping them somewhere current, findable, and owned. That is what the policy library in the portal is for, and here is how it works when the documents come to you.
Where the library lives and what is in it
If your engagement with Cloud Sentry includes managed compliance, the Policies link in the portal navigation opens your company's policy library. It holds the documents we maintain on your behalf, organized into three kinds:
- Information security policies. Acceptable use, access control, incident response, vendor management, the set an auditor expects to see for SOC 2.
- Standard operating procedures. The short, practical "how we do this" documents that sit next to the policies and explain the day-to-day.
- Reference materials. Onboarding checklists, joiner, mover, and leaver runbooks, and anything else specific to your environment.
Companies without managed compliance will not see the Policies link at all. That is deliberate; the library only appears for accounts where the documents exist. There is no empty shell to wonder about.
Finding the document you need
The index lists every document with its title, a one-line summary, and the date it was last updated. The search box at the top runs a full-text search across titles, headings, and body text, and it highlights the matches so you can see why a result came up.
If you know the topic but not the exact title, search the topic word: "incident," "vendor," "MFA." Search treats your input as a single phrase, so a two-word query matches that phrase exactly. You are looking for the answer to an auditor's question, not playing a guessing game with file names.
Reading and versioning a document
Open any document and you get a clean rendered view, not a download wall:
- A table of contents on the side, so you can jump to the section the question is about.
- The full body in plain prose, readable in the browser.
- A Last updated stamp at the top, so you can tell at a glance how fresh it is.
Documents are versioned. The version you see is always the current approved one, because each document is owned by a Cloud Sentry teammate who reviews it on a cadence (quarterly for active policies, annually for the rest). If you need a specific older version for an audit period that has already closed, file a request on the compliance topic and we will pull it for you.
This is the part that matters more than it sounds. Evidence is not a thing you produce in a sprint before the audit. It is what falls out of running the environment properly the whole time. A policy that gets reviewed on a schedule, by a named owner, with a version history behind it, is evidence on its own. SOC 2 is paperwork with consequences, and the consequence of stale paperwork is the lost afternoon from the opening of this article.
The documents in your library are yours, and sharing one with an auditor or a prospect running a security review is expected. There are two practical paths. For colleagues inside your own organization, the Share button copies a link that requires a Cloud Sentry sign-in. For an outside recipient, use Export PDF and send the file directly; the PDF carries the version stamp, so the auditor knows exactly which version they are reading and you do not have to explain it.
When the recipient can read the exact approved version, with the date and the version on the page, the back-and-forth disappears. The auditor self-serves; you stay out of the email thread.
When something looks out of date
If a policy describes something that no longer matches how your team works, the document is wrong, not the world. Tell us. File a request on the compliance topic with a one-line note about what is stale, and we update the document. The next time you open the library, the new version is there. Same goes for typos and broken cross-references. We want the library correct, because a correct library is the difference between an audit that goes quietly and an audit that becomes an archaeology project.
Walk back to that auditor's email. With the library in the portal, it stops being a research assignment. You open Policies, search the topic, confirm the Last updated date, export the PDF, and send it. The document you need is the document you get, current and trustworthy, because someone has been keeping it that way all along.
So the question worth sitting with is this: the next time an auditor or a prospect asks for a policy, do you want to go looking for it, or do you want it to already be findable?