What you can get done with your assistant

Once your assistant is connected to UprootSecurity, it can do the compliance legwork rather than just look things up: triage what's failing, file evidence against the right test, run a vendor review end to end, work a risk through the register, and move a policy along its lifecycle. Ask for the outcome in plain language — you never have to know what a capability is called, and your assistant finds it. Here are the five jobs worth handing it, with a prompt you can paste for each.

One rule runs through all of them: reading changes nothing, so anyone in your organization can do it. Writing anything — creating, editing, filing, publishing — needs Owner or Administrator, and Members and Auditors get the read half. Where a job narrows further than that, it's called out below.

Triage your compliance posture

Start here. Your assistant can pull your failing tests, explain what each one is actually checking, tell you who owns it and what evidence it's waiting on, then hand you a short worklist instead of a dashboard. It sees exactly what you'd see clicking through those tests yourself. This is read-only, so anyone can run it.

Which of my SOC 2 tests are failing right now? For each one tell me who owns it,
what evidence it's missing, and what I'd have to do to make it pass. Put the
quickest wins first.

Still yours: deciding which gaps are real. A test can fail because you genuinely have a hole, or because you handle that control a different way — the assistant can't tell those apart for you.

Close the evidence loop

An Upload test is one you satisfy by attaching a document as proof, and most of them fail for a boring reason: the document exists, it's just not filed. If your assistant can already reach the document — a shared drive, a repo, your own machine — it can pull it and attach it to the right test. Confirming the upload re-evaluates that test automatically, so don't ask it to re-run the test afterwards; ask it to read the result back. This works on Upload tests only, since integration tests collect their own evidence. Filing evidence needs the Owner or Administrator role.

Our latest penetration test report is in the security folder on my drive. Find the
test that's asking for it, file it as evidence, then tell me whether that test
passed.

The mechanics — and the one real constraint, that a plain chat assistant can read your tests but can't move a file — are in Uploading evidence with your assistant.

Still yours: confirming the document is the one your auditor asked for. Your assistant matched a filename; you're the one accountable for the evidence sitting in your audit file.

Run a vendor review end to end

A vendor review has a fixed shape, and your assistant can walk the whole of it:

Add Acme Analytics as a vendor — they process our customers' support tickets. Open a
review, build a questionnaire from our standard template, and give me the link to
send their security team.

Then, once the vendor has replied:

Acme answered the questionnaire. Walk me through the findings, and tell me which
ones you'd put in our risk register and why, given we only send them ticket data.

Still yours: the vendor's risk level, which findings become tracked risks, and the call that the review is finished. Findings aren't promoted automatically — your assistant proposes, you decide. And don't let it answer the questionnaire on the vendor's behalf; that's an attestation about someone else's security.

Work the risk register

Your risk library is a set of pre-written risks with the framing an auditor already recognizes. Your assistant can search it against something that changed in your business, tell you what's missing from your register, add what fits, and then take a risk through its assessment. Have it write a custom risk only when nothing in the library covers the situation. Working the register needs the Owner or Administrator role.

We just started storing customer data in a second region. Check the risk library for
anything about data residency and backups, tell me what's already in our register,
and add the ones that apply to us.

Still yours: the scores and the treatment decision. Whether you accept, mitigate or transfer a risk is your organization's stated position — tell your assistant what you actually did rather than letting it fill in a plausible answer.

Move a policy through its lifecycle

Policies follow a strict path: draft, in review, approved, published. If a reviewer wants changes instead, the policy goes back to its author to revise. Your assistant can pull the current draft, edit it, send it for review, and publish it once it's approved. Reopening a published policy always creates a new version, so the previously published one stays intact for your auditor. Policies go by ownership as well as role: you can work on the policies you own, your organization's owner can work on any of them, and approval is the organization owner's alone — an author can't approve their own draft.

Our access control policy draft doesn't say anything about revoking access when
someone leaves. Add a section describing what we actually do — the offboarding
checklist in our ticketing tool — and send it for review.

Still yours: the approval. An auditor reads an approval as a named person signing off on the wording, not as a step that got completed.

Where the line sits

The pattern across all five: your assistant does the gathering, the drafting and the filing; you make the attestations — the claims a named person has to stand behind. Nothing stops it technically: an assistant holding your key can approve a policy, accept a risk and complete a vendor review. Keeping those calls yours is what makes the record defensible when someone asks who decided. What to keep human covers each of those calls in detail.