Use Case

Audit fieldwork evidence request fulfillment
on the engagement record, not in a spreadsheet the auditor watches over your shoulder

Audit fieldwork lands as a list of fifty to four hundred evidence requests with a fourteen-day clock. Most internal security and GRC teams run the response from a shared spreadsheet, an email inbox, and three Slack channels. Evidence stalls on the wrong owner, samples drift between what the auditor asked for and what the team produced, the same artefact is re-pulled because the prior response is invisible, and the audit closes with carry-forward observations no one expected. Run audit fieldwork evidence request fulfillment as a structured workflow on the engagement record so each PBC request becomes a tracked item with a named owner, a documented sample scope, a captured response, and an activity log entry that the auditor reads against the same record the security team operates against.

Get Started Free

No credit card required. Free plan available forever.

Run audit fieldwork as a structured engagement, not a shared spreadsheet

Every internal security, GRC, and compliance team that operates against an external audit carries the same recurring cycle. The auditor delivers a list of fifty to four hundred evidence requests with a fourteen-day clock. The team scrambles into a shared spreadsheet, three email threads, and a Slack channel called audit-fieldwork-2026. Owners are ambiguous for the first three days, samples drift between what the auditor asked for and what the team produced, the same artefact is re-pulled because the prior response is invisible, and the audit closes with carry-forward observations no one expected. The next year cycle starts from a fresh spreadsheet because nothing survived. Run audit fieldwork evidence request fulfillment on the engagement record so each PBC item is a tracked request, each response cites the live operating evidence, each sample selection is documented, each release is gated and watermarked, and each follow-up lands as a state transition on the original item.

The workflow composes with the rest of the audit operating model. The upstream evidence retention discipline that decides what is kept and for how long runs on the audit evidence retention workflow. The customer-facing release pipeline for SOC 2 reports, ISO 27001 certificates, and pentest attestations runs on the customer security evidence room. The cross-framework control mapping that turns one canonical control into many citations runs on the control mapping crosswalks workflow. The compliance certification cycle the fieldwork engagement supports runs on the compliance audits workflow. The published rules the fieldwork response reads against (the per-tier handling discipline for tier 3 and tier 4 data, the labelling discipline, the cross-border transfer mechanism, the retention schedule) live in the data classification policy template so the auditor reads the rule alongside the evidence rather than asking for a separate policy document each time. The audit fieldwork engagement sits in the middle of these as the in-cycle response discipline that turns a recurring fire drill into a queryable operating record.

Eight request types the fieldwork engagement handles as structured items

Most PBC lists across SOC 2, ISO 27001, PCI DSS, NIST SP 800-53, and HIPAA audit cycles reduce to a small number of recurring request types. Each type has a documented evidence source, a documented release pattern, and a documented sampling expectation so the team responds from the live record rather than from a freshly authored summary.

Request type	What the auditor commonly asks for	How the workflow handles it
Policy and procedure pull	The current information security policy, the access control policy, the change management procedure, the incident response plan, the vulnerability management policy, the data classification standard, the vendor management policy, the cryptographic key management standard, and the acceptable use policy as of the observation period start.	Pulled from document management as the canonical versioned artefact with the effective date, the named policy owner, the review cadence, and the approval signature. The released artefact is the current version unless the auditor requests the period-end version, in which case the prior version with the documented approval date is released alongside an evidence-of-change note. Re-authoring a policy excerpt for the audit produces a parallel record the next cycle has to reconcile and should be avoided.
Configuration baseline sample	A sample of production server configurations against the documented hardening standard, a sample of cloud account or workload configurations against the cloud security baseline, a sample of database parameter configurations, a sample of network access control list entries, and the current TLS configuration of in-scope endpoints.	Pulled from scanner output where the configuration is observable from the network (TLS configuration via the TLS module, missing security headers via the headers module, exposed services via port scanning) and attached as the scan result snapshot for the named observation date. Internal configurations the platform does not scan are pulled from the configuration-management source of record and attached with the named system owner. The released artefact carries the capture timestamp; the auditor reads the snapshot rather than a freshly produced description.
Vulnerability scan and finding history	The vulnerability scan schedule for the observation period, a sample of scan results across the period (typically twelve scans selected at the auditor sampling rate), the open finding register at the observation period end, a sample of finding records across the severity range with the full remediation history, the retest evidence for closed critical findings, and the documented exception register.	Findings management exports the requested sample as CSV with the finding identifier, the title, the CVSS 3.1 vector, the severity, the open date, the close date, the named owner, the linked engagement, the linked asset, the retest reference, and the activity log entries that show the state transitions. The auditor reads the live finding record where deeper context is needed. Pull from the platform; do not author a fresh summary the auditor reads against.
Access review and joiner-mover-leaver evidence	The quarterly access review register, a sample of completed access reviews with the named reviewer attestation, the joiner records for new hires during the period, the leaver records for departures during the period, the mover records for role changes during the period, the privileged-access review record, and the segregation-of-duties review record.	Team management exports the workspace access history for the named period with the user, the role, the granted-on date, the revoked-on date, and the named approver. The activity log captures the actor and the timestamp for every membership change so the auditor reads the actual access chronology rather than a reconstructed list. Joiner-mover-leaver records that span systems outside the platform are pulled from the identity provider with the platform record cited as the supporting evidence for the in-scope workspace.
Penetration test attestation and report references	The penetration test engagement records covering the observation period, the attestation letters issued at the close of each engagement, the executive summary of each report, a sample of the findings raised by the test, the remediation evidence for findings the test discovered, and the retest evidence where the engagement included retesting.	The pentest engagement record holds the scope, the testing window, the methodology, the testing firm reference, and the report version. The attestation letter is the redacted artefact the auditor receives in most cases; the full report releases through the watermarked client portal with NDA gating only where the audit scope demands it. AI report generation composes the executive summary release from the engagement record so the released summary matches the internal engagement at release time.
Change management sample	A sample of production change records from the observation period with the change description, the named change requester, the named approver, the documented testing evidence, the deployment record, the post-change verification, and the rollback plan where applicable.	Where the change touches the platform (a new engagement type, a workflow change, a feature flag rollout, an access control change), the engagement record and the activity log hold the change chronology. Where the change touches systems outside the platform, the source of record is the change management system; the platform evidence cites the source rather than duplicating it. The auditor reads the change trail on one record per change rather than across three ticketing systems.
Walkthrough demonstration	Demonstrate the end-to-end vulnerability management workflow from scan trigger through finding open, triage, remediation, retest, and close. Demonstrate the end-to-end change management workflow from request through approval, testing, deployment, and verification. Demonstrate the end-to-end incident response workflow from detection through containment, eradication, and post-incident review.	The walkthrough is performed live against the platform with the named attendees recorded on the engagement, the demonstrated step sequence captured as a note with timestamps, and the artefacts referenced during the demonstration cited on the request item. The walkthrough note is the canonical record the next year audit reads against; recording the walkthrough demonstration is a useful supplement but the structured note is what survives. Walkthroughs that occur off-record produce a re-walkthrough request the next cycle.
Incident response evidence	The incident response plan as of the observation period, a sample of incidents detected and managed during the period, the documented severity rating per incident, the named incident commander, the timeline from detection through closure, the post-incident review notes, the customer notification record where contractually obligated, and the regulator notification record where statutorily obligated.	Incident response engagements hold the incident timeline, the named responders, the activity log of state transitions, and the linked findings or evidence. The auditor reads the engagement record per sampled incident; the platform provides the activity log export as the canonical chronology. Notifications to customers and regulators have their own evidence chain (the notification content, the named author, the timestamp, the recipient list) and surface as engagement attachments rather than as recreated summaries.

Six failure modes that quietly break audit fieldwork response

Most fieldwork failures look like sensible defaults: open a spreadsheet, route by email, author a fresh summary for the audit, attach a screenshot. The cost arrives at audit close as a deficiency assertion, a re-pull request, or a carry-forward observation the next year cycle inherits.

Evidence lives in a shared spreadsheet the auditor watches over your shoulder

The PBC list arrives as a spreadsheet, the team fills in cells, the auditor pulls a copy at the end of fieldwork. The chain of custody is the spreadsheet; the evidence is screenshots and email attachments referenced in the cells. When the next year audit opens, the chronology is lost because nothing is on a maintained record. The fix is making the PBC list a structured engagement: each request is an item, each response is an artefact on the item, each follow-up is a state transition, and the activity log captures every change with timestamp and user attribution.

Parallel evidence trail authored for the audit diverges from the operating record

The team builds a SOC 2 evidence deck and a fieldwork response binder that describe what should be happening rather than pulling from the live record. The auditor compares the binder to the operating record and finds the inconsistencies. The fix is responding from the live record: cite the engagement, the finding, the scan, the activity log entry, the policy version in document management. If the live record cannot answer the question, the gap is the audit finding, not a missing summary.

Samples drift between what the auditor asked for and what the team produced

The auditor asks for twelve access reviews selected at random across the quarter; the team produces twelve access reviews from the easiest week to retrieve. The auditor reads the sample as a control failure when the population is non-random. The fix is capturing the sample selection criteria, the random-or-judgmental method, the named selector, and the selected sample IDs on the request item before the response is assembled, so the audit reads against the same sampling decision the team made.

Owners are unclear and requests stall on the wrong person

A request lands in a shared inbox or a Slack channel and waits for whoever has bandwidth. Three days pass and the named owner is still ambiguous. The auditor escalates and the team scrambles. The fix is routing each request to a named owner with RBAC at the moment the PBC list is ingested, with a documented response deadline on the item and notifications pushing pending and overdue requests to the named owner rather than to the room.

Walkthrough notes live in the head of the person who gave the walkthrough

The walkthrough goes well, the auditor leaves satisfied, and no one documents what was demonstrated. The next year audit asks for the same walkthrough and the person who gave it has left. The team re-walks an updated process and the auditor reads the change as undocumented. The fix is capturing the walkthrough note on the request item with the named attendees, the demonstrated step sequence, and the artefact references discussed, so the next cycle reads against a defensible prior.

Sensitive artefacts release as freeform email attachments

A SOC 2 report from a prior cycle, raw finding records, configuration baselines, and customer data samples all leave the team as email attachments. The chain of custody is the email server. When a regulator-driven inquiry asks how a sensitive artefact was shared, the team cannot answer. The fix is releasing through the branded client portal or watermarked document export, with the countersigned NDA gating the release and the access scope carrying an expiry tied to the audit close.

Six fields every PBC request item has to record

A defensible response is six concrete fields on the request item, not a row in a spreadsheet and a folder of attachments. The fields make the chronology reconstructable when the next year audit, an internal review, or a regulator-driven inquiry asks how the team responded to what, when, and with what evidence.

Request identity and audit reference

The original auditor request identifier (the PBC line item number or RFI reference), the audit reference (SOC 2 Type 2 observation period, ISO 27001 surveillance audit, PCI DSS quarterly check, internal audit cycle), the control area (CC6.1 logical access, CC7.1 vulnerability management, A.5.34 privacy, Requirement 10 logging), and the requested artefact (policy, configuration, log, sample, walkthrough, attestation). The fields are what allow the next cycle to read continuous with the prior cycle rather than starting from a fresh spreadsheet.

Sample scope and selection method

For sampling requests, the population description, the sample size, the selection method (random with a documented seed, judgmental with a documented rationale, statistical with a documented confidence level), the named selector, and the selected sample identifiers. Sample-related findings against the platform are reproducible across audit cycles because the selection method lives on the engagement rather than in the head of one operator.

Named owner and response deadline

The named internal owner responsible for assembling and submitting the response, the RBAC role granted to that owner on the engagement, the documented response deadline, and the escalation path when the deadline approaches. Notifications push pending and overdue requests to the owner on the documented cadence so the queue does not silently fall behind.

Response artefacts and provenance

The artefacts attached as the response (the document version, the CSV export, the watermarked PDF, the configuration snapshot, the walkthrough note) with the provenance for each: where the artefact was pulled from (which engagement, which finding, which scan, which activity log query), the named owner who pulled it, the capture timestamp, and the redaction or watermarking applied. The auditor reads the artefact and the provenance together so the chain of custody is reconstructable.

Release channel and NDA gating

The release channel (branded client portal scoped to the named auditor reviewer, watermarked download via signed URL, NDA-gated walkthrough, in-person review at a structured walkthrough), the countersigned NDA reference where applicable, the access expiry tied to the audit close date, and the named owner responsible for revoking access at audit close. Access without a revocation owner is access that drifts beyond the audit window.

Auditor response, follow-up, and reconciliation

The auditor acceptance or follow-up note (request fulfilled, clarification needed, re-pull requested, deficiency asserted), the linked follow-up items, the management response where a deficiency is asserted (the named owner, the remediation plan, the target evidence, the next-cycle deadline), and the timestamp of every state transition. The follow-up chronology lives on the original item rather than as a new thread so the audit lookback reads as one record per request.

Eight queues the fieldwork engagement runs in parallel during the active cycle

During an active audit cycle the engagement runs eight queues concurrently. Each queue has a named owner, a documented cadence, and an escalation rule so requests, sample selections, releases, and revocations do not silently fall behind between morning stand-ups.

Open PBC requests queue with each unanswered request, the named owner, the deadline, and the request type. The view the audit liaison reads against the calendar.
Overdue request queue with every request past its deadline, the assigned owner, the elapsed time, and the escalation owner. The view the GRC lead reads on the morning stand-up during fieldwork.
Sample selection queue with each sampling request awaiting the selection method, the named selector, the population description, and the selected sample identifiers. The view the assurance owner reads to confirm sampling discipline before responses release.
Pending release queue with each response awaiting the NDA gate confirmation, the watermarking decision, and the release channel selection. The view the named approver reads before sensitive artefacts leave the workspace.
Follow-up queue with each auditor clarification, re-pull request, or deficiency assertion pending team response. The view the audit liaison reads to keep the chronology continuous on the original request item.
Management response queue with each deficiency assertion pending a documented remediation plan, the named owner, the target evidence, and the next-cycle deadline. The view the security operations leader reads to staff the remediation work.
Walkthrough preparation queue with each scheduled walkthrough demonstration, the named attendees, the demonstrated step sequence, and the artefact references to cite. The view the named demonstrator reads before the walkthrough lands on calendar.
Access revocation queue with each auditor access scope eligible for revocation as the audit closes, the named owner who closes the loop, and the timestamp of the revocation. Audit access that lingers past close is access that drifts.

How audit fieldwork response runs in SecPortal

The audit fieldwork engagement rides on the same feature surfaces the rest of the security programme already uses. The audit opens as an engagement on the workspace, each PBC item lands as a tracked request, document management holds the response artefacts, findings management feeds the vulnerability and remediation samples, compliance tracking maps the requested control areas, team management role-based access scopes who can release what, the branded client portal hosts the auditor reviewer access, the activity log captures every state transition, and AI report generation composes summaries from the live record.

Audit as an engagement

Each audit cycle opens on the engagement record with the named auditor, the observation period, the framework reference, and the PBC register. The engagement is the queryable spine of the cycle so the chronology survives beyond fieldwork close.

PBC items as tracked requests

Each PBC line lands as a tracked request on the engagement with the request type, the control area, the named owner, and the deadline. Bulk import ingests the auditor list when it is shared as CSV so day one is not a re-keying exercise.

Response artefacts in document management

Document management holds the policy versions, the configuration snapshots, the walkthrough notes, the attestation letters, and the watermarked exports as versioned objects with effective dates and named owners.

Vulnerability samples from findings

Findings management exports the requested vulnerability sample with the CVSS vector, the open and close dates, the remediation history, the retest evidence, and the named owners so the auditor reads the live record rather than a freshly authored summary.

Control area mapping

Compliance tracking maps each PBC request to the underlying SOC 2 Trust Services Criteria, ISO 27001:2022 Annex A control, PCI DSS requirement, or NIST SP 800-53 control family so the audit chronology and the control inventory stay aligned.

RBAC across response owners

Team management scopes engagement access to the named response owner per request, the named release approver, the redaction owner, and the access-revocation owner. Sensitive artefacts route through the approver before reaching the auditor channel.

Branded portal for auditor access

The branded client portal on a tenant subdomain hosts the auditor reviewer access scoped to the named auditor. The reviewer sees only the scope authorised on the engagement so the release surface is bounded rather than open to broadcast download.

MFA on sensitive evidence

MFA enforcement on the workspace and the portal protects the audit response surface where SOC 2 reports, pentest attestations, raw finding records, and configuration baselines are accessed. The named auditor reviewer cannot reach the gated artefact without the second factor.

AI summaries from the live record

AI report generation composes the executive summary, the vulnerability summary, and the post-audit internal read from the live engagement and findings records. The team reviews and approves the composition before release so the released artefact reads against the same source as the operational queue.

Notifications surface pending requests

Notifications push pending PBC items, overdue requests, pending releases, and pending sample selections to the named owners on a documented cadence so the queues do not silently slip past their deadlines.

Activity log as the audit chain

The activity log captures every PBC request open, every response submission, every sample selection, every release, every revocation, and every follow-up exchange with timestamp and user attribution. The CSV export is the response provenance the next year audit reads against.

Watermarked sensitive exports

Sensitive artefacts release with watermarking that carries the auditor identifier and the release date, NDA gating that requires the countersigned agreement on file, and an access expiry tied to the audit close date so circulation outside the named auditor is traceable and time-bounded.

Five reads the fieldwork engagement actually drives

The reads that drive fieldwork response work are not the static project plan. They are the live views the audit liaison, the GRC lead, the security operations leader, and the named approver use between morning stand-ups during active fieldwork.

Open PBC requests

Every unanswered request with the request type, the named owner, the deadline, and the elapsed time. The view the audit liaison reads against the audit calendar.

Sample selection register

Every sampling request with the population, the size, the selection method, the named selector, and the selected identifiers. The view the assurance owner reads before responses release.

Release-decision queue

Every sensitive artefact pending release with the NDA gate confirmation, the watermarking decision, and the release channel selection. The view the named approver reads before artefacts leave the workspace.

Deficiency and management response

Every asserted deficiency with the documented remediation plan, the named owner, the target evidence, and the next-cycle deadline. The view the security operations leader reads to staff the remediation work.

Activity log export

Every state change across PBC items, sample selections, releases, follow-ups, and revocations with timestamp and user attribution. The CSV export is the response provenance the next year audit reads against.

Post-audit internal summary

The AI-composed read of requests fulfilled, owners overloaded, recurring deficiency patterns, and evidence gaps to remediate before next cycle. The view the GRC lead and the security leader read at the post-audit retrospective.

What auditors expect against each major framework

Audit fieldwork rides through several framework operating models in parallel. The frameworks below all expect evidence that covers a structured request register, a documented sampling method, a captured response provenance, a managed deficiency log, and a chronology the next year audit can read against.

Framework	What the audit expects
SOC 2 Trust Services Criteria	CC1.x (control environment, including documented roles and named owners), CC2.x (communication and information), CC4.x (monitoring activities, including the audit liaison function), CC5.x (control activities, including documented sampling), CC6.x (logical and physical access), CC7.x (system operations and vulnerability management), and CC9.x (risk mitigation) all read against the audit fieldwork engagement. The structured PBC register, the activity log of every state transition, the documented sampling decisions, and the management responses to deficiencies are the SOC 2 Type 2 evidence chain.
ISO 27001:2022	Annex A 5.1 (policies for information security), 5.34 (privacy and protection of PII), 5.35 (independent review of information security), 5.36 (compliance with policies, rules and standards for information security), 5.37 (documented operating procedures), 6.3 (information security awareness, education and training), 8.34 (protection of information systems during audit testing), and the broader Clause 9 (performance evaluation) read against the workflow. The certification body and the surveillance auditor read the structured request register and the documented response provenance.
PCI DSS v4.0	Requirement 10 (log and monitor all access to system components and cardholder data), Requirement 11 (test security of systems and networks regularly), and Requirement 12 (support information security with organisational policies and programs) read against the audit fieldwork engagement when the QSA performs the assessment. The activity log export, the documented sample selection, and the structured response provenance are the QSA evidence chain.
NIST SP 800-53 Rev. 5	CA-2 (control assessments, including the assessor independence and the assessment procedures), CA-5 (plan of action and milestones, the management response chain to deficiencies), CA-6 (authorisations), CA-7 (continuous monitoring), and AU-6 (audit record review, analysis, and reporting) read against the workflow when the assessment supports a federal customer relationship or an internal continuous-monitoring programme.
HIPAA Security Rule	Section 164.308(a)(1)(ii)(D) (information system activity review) and Section 164.316(b) (documentation requirements with a six-year retention floor) read against the workflow when the workspace operator is a covered entity or business associate. The structured PBC register, the documented sample selection, and the retained response provenance are the HIPAA audit chain.
Internal audit and SOX (where the operator is in scope)	The internal audit function operating against the Institute of Internal Auditors Standards reads the workflow as the engagement record per audit cycle. SOX 404 attestation work (where the operator is a public company or a subsidiary in scope) reads the workflow as the IT general controls evidence chain across logical access, change management, and computer operations.

Where audit fieldwork sits in the rest of the security operating model

Audit fieldwork response is downstream of evidence retention, compliance certification, and control mapping; upstream of the management response cycle and the next year audit engagement. The artefacts the fieldwork engagement cites feed the customer evidence room and the cyber-insurance evidence pack so the same source survives across audit, customer, and insurance audiences.

Upstream and adjacent

The retention discipline that decides what evidence is kept and for how long runs on the audit evidence retention workflow, the certification cycle the fieldwork supports runs on the compliance audits workflow, and the control mapping that turns one canonical control into many framework citations runs on the control mapping crosswalks workflow.

Downstream and adjacent audiences

The deficiency log feeds the control gap remediation workflow, the customer-facing release pipeline that reuses the same SOC 2 and pentest attestation runs on the customer security evidence room, the cyber-insurance audience packaging runs on the cyber insurance security evidence workflow, and the leadership read-out lands on the security leadership reporting workflow.

Pair the workflow with the long-form guides and the framework references

The audit fieldwork engagement is operational. The surrounding long-form guides explain the underlying audit programmes, the compliance operating models, and the framework expectations the workflow has to satisfy. Pair this workflow with the SOC 2 compliance guide for the SOC 2 Trust Services Criteria background, the ISO 27001 audit checklist for the certification fieldwork operating model, the PCI DSS assessment guide for the QSA-led fieldwork cycle, and the security compliance automation guide for the broader operating-model context. The framework references that mandate the audit evidence include the SOC 2 framework page, the ISO 27001 framework page, the PCI DSS framework page, the NIST SP 800-53 framework page, and the HIPAA framework page. The economics of the artefact-side of audit response, including the per-class reuse multiplier for scan executions, findings, retests, exceptions, closures, and activity log entries, is covered on the vulnerability evidence reuse across audits research, which reads against the same live engagement record this workflow operates on.

Buyer and operator pairing

The audit fieldwork engagement is the workflow GRC and compliance teams run as the in-cycle response discipline, internal security teams run as the upstream evidence source, AppSec teams feed with the vulnerability sample and the remediation history, vulnerability management teams feed with the SLA-tier sample and the exception register, CISOs read as the management response trail at the post-audit retrospective, and security operations leaders run as the queue execution discipline that keeps the response from slipping behind the fourteen-day clock.

What a good audit fieldwork engagement feels like

Every request has an owner

No request sits in a shared inbox waiting for someone with bandwidth. Each PBC item routes to a named owner with the RBAC scope to respond and a documented deadline that shows up on the notification queue.

Every response cites the live record

No fresh summary authored for the audit. Responses cite the engagement, the finding, the scan, the activity log entry, or the policy version so the auditor reads the live operating evidence rather than an interpretation.

Every sample is documented

No drift between what the auditor asked for and what the team produced. The selection method, the named selector, and the selected identifiers land on the request item before the response is assembled.

Every release is gated and watermarked

No freeform email attachments. Sensitive artefacts release through the branded portal or a watermarked export with NDA gating, access expiry tied to audit close, and a named revocation owner.

Every follow-up stays on the item

No new threads for clarifications, re-pulls, or deficiency assertions. The follow-up chronology lives as state transitions on the original request item so the audit lookback reads as one record per request.

Next year reads from this year

The next audit opens against the prior engagement so the carry-forward observations, the documented samples, the named responders, and the deficiency log all read continuous rather than rebuilt from a fresh spreadsheet.

Audit fieldwork response is the in-cycle discipline that turns a recurring fire drill into a queryable operating record. Run it on one engagement per audit so every PBC item, every response, every sample, every release, every follow-up, and every revocation lives on a single trail rather than scattered across a spreadsheet, an inbox, and three Slack channels that disappear at the end of fieldwork.

Frequently asked questions about audit fieldwork evidence request fulfillment

What is audit fieldwork evidence request fulfillment?

Audit fieldwork evidence request fulfillment is the operational workflow internal security, GRC, and compliance teams use to respond to the structured list of evidence requests an auditor issues during fieldwork. The list is commonly called the PBC list (Provided By Client), the evidence request list, the request schedule, or the audit RFI list. The workflow holds each request as a tracked item on the engagement, routes it to a named owner with a documented deadline, captures the response artefacts with their provenance, runs sample selection with a documented method, releases sensitive artefacts through a controlled channel, and reconciles follow-up exchanges as state transitions on the original item. The activity log captures every change with timestamp and user attribution so the audit reads against the same record the security team operates against.

How is this different from the audit evidence retention workflow?

The audit fieldwork engagement is the inbound response side: an auditor sent a PBC list and the team has fourteen days to respond. The audit evidence retention workflow is the upstream discipline that decides what evidence is kept, for how long, and how it is disposed. Run them together: retention determines what is available to cite in a fieldwork response; fieldwork fulfillment is the in-cycle workflow that pulls the retained evidence into structured request responses. Without retention, fieldwork is a re-authoring sprint; without fieldwork structure, retention does not survive the audit chronology.

How is this different from the customer security evidence room?

The customer security evidence room is the customer-facing release workflow: NDA-gated SOC 2 access for prospects, attestation letter releases to customers, subprocessor change notifications, branded portal walkthroughs. The audit fieldwork engagement is the auditor-facing response workflow: a SOC 2 examiner, an ISO 27001 certification body, a PCI QSA, or an internal auditor issued a PBC list and the team is responding. The artefacts are often shared (the SOC 2 report, the pentest attestation, the vulnerability summary) but the audiences, the gating, and the chronology differ. Run them as related engagements that read against the same source artefacts.

How does the workflow handle sample selection for the auditor?

When the auditor requests a sample (twelve access reviews from the last quarter, eight finding records across the severity range, four onboarding records from the last six months), the sample selection criteria, the random-or-judgmental method, the named selector, and the selected sample identifiers are captured on the request item before the response is assembled. Random selection uses a documented seed so the selection is reproducible. Judgmental selection records the named rationale (the highest-severity findings, the longest-open findings, the cross-asset coverage) so the auditor reads the sampling decision rather than a black box. The next year audit reads against the same sampling discipline rather than starting from scratch.

How does the workflow keep the audit response consistent with the operating record?

Responses cite the live record rather than authoring a parallel summary. Vulnerability scan history, finding remediation records, the engagement activity log, the CVSS calibration record, the retest evidence, the credential rotation log, and the team membership history are all pulled from findings management, scanner-info exports, the activity log, the engagement record, and document management. AI report generation composes a higher-level summary where the auditor asks for one, but the summary cites the underlying engagement so the auditor can drill into the record. The parallel-evidence-trail anti-pattern that produces audit findings is avoided because the response is the live record, not an interpretation of it.

How does the workflow handle sensitive evidence releases?

Sensitive artefacts (the full prior-cycle SOC 2 report, raw finding records, configuration baselines, customer data samples) release through the branded client portal scoped to the named auditor reviewer or as a watermarked document export with a signed URL. The countersigned NDA on file is a structured prerequisite on the engagement; without it, no release. The watermark carries the auditor identifier and the release date so circulation outside the named reviewer is traceable. The access scope carries an expiry tied to the audit close date and a named revocation owner so the auditor does not retain access beyond the audit window.

How does the workflow handle auditor follow-up and deficiency assertions?

When the auditor returns with a follow-up question, a clarification, a re-pull, or a deficiency assertion, the exchange lands on the original request item as a state transition rather than as a new thread. The reconciliation reads against the prior response, the prior artefact reference, and the prior owner so the chronology is reconstructable. When the auditor asserts a deficiency, a management response item opens on the engagement with the named owner, the documented remediation plan, the target evidence the next cycle will read, and the timeline for completion. The deficiency log carries forward to the next audit so the assurance discipline is continuous rather than reactive.

How does the workflow close out at the end of fieldwork?

When fieldwork closes, the engagement record holds the full PBC request register, the response artefacts, the sample selections, the walkthrough notes, the deficiency log, the management responses, and the activity log of every state transition. AI report generation composes the internal post-audit summary (requests fulfilled, owners overloaded, recurring deficiency patterns, evidence gaps to remediate before next cycle) from the same record. The auditor access scope is revoked on the close date with the timestamp and named owner captured on the activity log. The next audit opens against the prior engagement so carry-forward observations and the documented samples read continuous rather than rebuilt.

Does SecPortal replace the auditor or perform the audit?

No. SecPortal is the operational record the internal security, GRC, and compliance teams run the fieldwork response against. The auditor is independent and performs the audit against the operator. SecPortal holds the engagement, the PBC register, the response artefacts, the activity log, and the documented controls so the response is structured rather than scattered. The independent auditor reads the same record the security team operates against and issues the opinion or certification against the documented evidence.

What if multiple audits run in parallel?

Most enterprise programmes carry two to six concurrent audit cycles (SOC 2 Type 2, ISO 27001 surveillance, PCI DSS quarterly, internal audit, customer-driven assessments, regulator-driven inquiries). Each audit opens as a separate engagement on the workspace so the PBC registers do not collide and the named owners do not get cross-routed. Where the same evidence answers multiple audits (a single SOC 2 report citation, a single pentest attestation, a single vulnerability summary), the underlying engagement is cited by each fieldwork engagement so the source remains canonical and the response provenance is consistent across audits.

How it works in SecPortal

A streamlined workflow from start to finish.

Open the audit as a fieldwork engagement and ingest the PBC list as structured items

When the auditor delivers the Provided By Client list (also called the evidence request list, the request schedule, or the audit RFI), each line item lands on the engagement as a tracked request: the audit reference, the control area, the requested artefact, the evidence type (policy, configuration, log, sample of records, walkthrough, attestation), the sample size and selection criteria, the named auditor requester, the named internal owner, the original due date, and the response status. The list is the engagement spine; nothing happens off it.

Route each request to a named owner with RBAC and an explicit response deadline

Team management role-based access control assigns each request to a named owner on the workspace and grants the access scope that owner needs to complete the response. The named owner reads the request on the engagement, not in an email thread, and the response deadline is captured on the item so the auditor-facing clock and the internal-team clock read against the same field. Owners with overdue requests surface on the notification queue and on the leadership read rather than discovered at the next status call.

Pull evidence from the operating record rather than recreating it for the audit

Most fieldwork evidence already exists on the operating record. Vulnerability scan results, finding remediation history, the engagement activity log, the CVSS calibration record, the retest evidence, the credential rotation log, and the team membership history are all queryable artefacts. The response cites the existing record and attaches the CSV or PDF export rather than authoring a fresh artefact for the audit. The auditor reads against the live operating evidence; the security team avoids the parallel-evidence-trail anti-pattern that produces audit findings.

Capture sample selections and walkthrough notes against the same item

When the auditor requests a sample (twelve access reviews from the last quarter, eight finding records across the severity range, four onboarding records from the last six months), the sample selection criteria, the random-or-judgmental method, the named selector, and the selected sample IDs land on the request item. When the auditor requests a walkthrough, the meeting note, the named attendees, the demonstrated step sequence, and the artefact references discussed land on the same item. The next year audit reads against the same record and the team does not reconstruct the sample method from email.

Submit responses through a controlled release channel with watermarking and NDA gating

Sensitive artefacts (the full SOC 2 report from the prior cycle, raw finding records, configuration baselines, customer data samples) release through the branded client portal or a watermarked document export rather than as a freeform email attachment. The countersigned NDA on file gates the release; the watermark carries the auditor identifier and the release date; the access scope carries an expiry tied to the audit close date. The named auditor reviewer reads the artefact on the same channel the security team controls.

Run reconciliation and follow-up loops as state events on the engagement

When the auditor returns with a follow-up question, a clarification, a re-pull, or a deficiency assertion, the exchange lands on the original request item as a state transition rather than as a new email thread. The reconciliation reads against the prior response, the prior artefact reference, and the prior owner so the chronology is reconstructable. Deficiency assertions trigger a management response item on the engagement with the named owner, the remediation plan, the documented evidence target, and the timeline the auditor will read at next year fieldwork.

Close the audit and stamp the evidence chain for the next cycle

When fieldwork closes, the engagement record holds the full request register, the response artefacts, the sample selections, the walkthrough notes, the deficiency log, the management responses, and the activity log of every state transition. AI report generation composes the internal post-audit summary (requests fulfilled, owners overloaded, recurring deficiency patterns, evidence gaps to remediate before next cycle) from the same record. The next audit opens against the prior engagement so the carry-forward observations, the documented samples, and the named responders all read continuous rather than rebuilt.

Features that power this workflow

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

Compliance tracking without a full GRC platform

Collaborate across your entire team

Every action recorded across the workspace

Your brand. Your portal. Your clients love it.

AI-powered reports in seconds, not days

Multi-factor authentication on every workspace

Notifications and alerts for the people who carry the work

Run audit fieldwork on the engagement record, not a spreadsheet

Structured PBC items, named owners, sample controls, watermarked releases, and a defensible response chain on a single workspace. Start free.