SOC 2 PBC request automation is the map from each recurring provided-by-client item to the collector that already produces the artifact. The list arrives, someone hunts screenshots, and the same five exports are rebuilt by hand. The collectors were often running already. They were not tied to the request ids. The client is the one in the audit. Rutagon builds that map and files the result in the GRC platform you already run.
The auditor's wording changes between firms. The control does not. We key the map on the control and the artifact type, and we hang the firm's sentence on the row as a label. The next firm can rename the request without forcing a new collector. Teams that key the map on the exact sentence rebuild the hunt every cycle.
The request list and the collectors
A PBC item in our map is a recurring ask: show admin access, show who can reach production data, show that a failover test happened, show an incident from detection through close. Each item points at a collector or is explicitly manual. A collector is a job that already writes a stable artifact. The admin role export is one. The failover-test pack is another, filed as SOC 2 disaster recovery test evidence. The PBC row does not re-explain those systems. It points at the artifact id they already produced.
Manual is a real status. An item with no collector keeps an owner and a due time inside the window. The point of the build is a short manual list that everyone can see, not a claim that every ask is automatic. Hiding the manual rows inside a folder called "automated" is how the sample slips.
Google's Directory API is a useful picture of what a collector reads when the PBC line is privileged admin. Role assignments, including indirect ones through a security group, are listed and paged until the token runs out. Google documents that listing behavior in the Manage roles guide. The PBC item stores the export id. It does not store a fresh screenshot taken because the request email arrived.
Other lines follow the same shape with their own collectors. A database-access line points at the production role export. A VPN line points at the group joined to last successful connection. A change-management line points at the change record you already file. We do not build a second copy of the evidence to satisfy the wording. We attach the id.
SOC 2 PBC request automation rows
Each recurring item is one row. The firm's label is text. The control id is yours. The collector id is a job name or the value manual. The latest artifact id and the time it was collected come from the collector. Fresh or stale comes from the window. The GRC request id is written back when the item is fulfilled.
firm_label: privileged-access-list
control_id: access-review
collector: workspace-role-assignments
artifact_id: export-id
collected_at: collector-time
fresh: true
grc_request_id: required
Stale artifacts are not offered as the default fulfillment. Evidence freshness tracking is the flag we honor. An override that attaches a stale file is visible and needs a reason. Silent reuse of last cycle's spreadsheet is the bug the map exists to stop.
Sampling is a view on this table, not a second hunt. Audit sampling evidence can draw from the same artifact ids. When the auditor asks for the population and then for a sample, both answers are lookups. The population is every artifact the collector wrote in the window. The sample is the subset they named. We do not assemble the sample by searching a drive.
Labels change, collectors do not
The first cycle is spent matching the firm's list to controls you already operate. Some lines are duplicates in different words. We collapse those onto one collector and keep both labels, so the response letter can quote their wording. Some lines are not controls you operate. Those stay manual or get an explicit "not in scope" with the reason your system description already uses. Inventing a collector to answer an out-of-scope line creates evidence you cannot defend.
The export the firm receives is generated from the map: their label, your artifact, the collected time, and a link or attachment inside the GRC you already run. A person still reads the cover note. The person does not rebuild the spreadsheet. That split is the production lesson. The first time we wire this, the cover note is where the hours were going, and the hours were going there because the artifact id did not exist. After the id exists, the note is a paragraph.
Requests that arrive mid-window for a one-off population are not forced into the recurring map. They are answered once and tagged as one-off. If the same one-off appears in the next cycle, it earns a collector. Promoting every novel sentence into a permanent job is how the map becomes a junk drawer.
What we will not pretend
The GRC you already run remains the place the firm looks. We do not ask you to replace it with a folder of JSON. When the GRC cannot store structured fields, the same row is attached to the request and the request id is still stored. The shape stays stable so the next cycle is a refresh of artifact ids, not a new template.
Access-review exports that the firm wants in a particular column order are a view. Exporting access-review evidence is that view. The PBC map points at it. Changing column order does not mean re-collecting the entitlements.
This map is security automation under the audit you are already in. Rutagon does not become the auditor by generating the pack. We make the recurring lines resolve to live artifacts, and we leave the manual lines visible. The next cycle should be boring. Boring is the feature.
Frequently Asked Questions
What is a collector in SOC 2 PBC request automation?
A job that already writes a stable artifact for a control: an admin-role export, a failover-test pack, a database-role list. The PBC row stores the artifact id and the time it was collected. The row does not restate how the collector works.
What happens to items that have no collector?
They stay manual, with an owner and a due time inside the window. Manual is a visible status. We do not mark those rows automated because a person once uploaded a file. If the same ask repeats next cycle, it can earn a collector then.
Why not key the map on the auditor's sentence?
Firms reword the same control. The map is keyed on your control id and the artifact type. Their sentence is a label so the response can quote them. Relabeling does not rebuild the collection job.
How are stale files kept out of the response?
The freshness flag has to be true for the default fulfillment. A stale artifact can be attached only with an override reason that stays visible. Last cycle's spreadsheet does not satisfy this window by being easy to find.
Where does the firm retrieve the pack?
In the GRC you already run. Each fulfilled item carries their label, the artifact id, and the request id. Sampling and the full population read the same ids. A drive search is not the retrieval path.
Ask us what your GRC platform isn't covering. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.