Customer security evidence room workflow
releases as recorded actions, not as forwarded attachments
B2B SaaS security teams field a recurring exercise: a customer security reviewer asks for the SOC 2 report, a prospect runs a TPRM review, a renewal cycle reopens the questionnaire backlog, a regulator-driven assessment rides through a customer relationship, and the internal team rebuilds the same evidence packaging from scratch each time. Run the customer security evidence room as a structured workflow on a customer engagement record so every release is a recorded action, every artefact carries an effective date, every NDA gates the release rather than the conversation, and every access scope has a named revocation owner.
No credit card required. Free plan available forever.
Run the customer security evidence room as a maintained workflow, not as a SharePoint folder
Every B2B SaaS security team carries the same recurring exercise: a customer security reviewer asks for the SOC 2 report, a prospect runs a TPRM review, a renewal cycle reopens the questionnaire backlog, a regulator-driven assessment rides through a customer relationship, and the internal team rebuilds the same evidence packaging from scratch each time. Most programmes operate the room as a shared inbox plus a SharePoint folder plus a verbal NDA agreement on a sales call. The artefacts circulate after expiry, the watermarking is inconsistent, the disclosure log lives in the head of one operator, and the customer-facing summary diverges from the internal record because somebody edited the slide three days before release. Run the customer security evidence room as a structured workflow on a customer engagement record so every release is a recorded action, every artefact carries an effective date, every NDA gates the release rather than the conversation, and every access scope has a named revocation owner.
The workflow composes with the rest of the customer security operating model. The per-questionnaire response that drafts answers from the canonical control library runs on the vendor security questionnaire response workflow. The internal evidence retention discipline that determines what is kept, for how long, and how it is disposed runs on the audit evidence retention workflow. The cyber-insurance-specific evidence packaging runs on the cyber insurance security evidence workflow. The control-mapping crosswalks that turn one canonical control into many framework citations run on the control mapping crosswalks workflow. The customer-evidence-room workflow sits upstream of all of these as the artefact discipline that feeds them with consistent, current evidence.
Eight artefacts the customer evidence room holds as canonical objects
The evidence room holds a small number of high-trust artefacts as canonical, versioned objects on the workspace. Each artefact has a named audience, a redaction or release rule, and a renewal trigger so the customer-facing release reads against the same record the internal team reads against.
| Artefact | Audience | Handling notes |
|---|---|---|
| SOC 2 Type 2 report | Customer security reviewer reading against the SOC 2 Trust Services Criteria, the prospect security team conducting a TPRM review, the existing customer renewing under stricter procurement requirements. | The full report is typically NDA-gated. The platform-side workflow holds the report version as a document with the issuance date, the observation period, the named auditor, and the named author who signed it. Release goes out only to reviewers who have countersigned the NDA. Watermark-on-export with the requester identifier and the release date so circulation outside the original recipient is traceable. |
| ISO 27001 certificate and Statement of Applicability | Customer reviewers in regulated industries asking for ISO 27001 evidence, suppliers reading against the ISO 27001:2022 Annex A controls, regulators reading the conformance attestation through the customer relationship. | The certificate itself is shareable; the SoA is more sensitive because it discloses scope and control selection. Hold both as document objects on the engagement so the certificate version, the certifying body, the certificate number, the issue date, the expiry date, and the SoA revision are queryable. Renewal expiry triggers a re-release to active reviewers so customers do not consume an out-of-date certificate. |
| Penetration test attestation letter | Customer reviewers asking for evidence that a third-party penetration test was performed, prospects reading against MSA security clauses that mandate annual testing, regulators reading the testing cadence through the customer relationship. | The full pentest report is rarely shared. The attestation letter is the redacted artefact: it captures the testing window, the testing firm, the scope (without raw asset detail), the methodology references, and a high-level severity-count summary. The full report stays internal. Hold the attestation as an engagement document with the testing firm reference, the engagement identifier, the issuance date, and the named author who signed it. |
| Vulnerability summary and remediation status | Customer reviewers asking how the programme identifies and remediates vulnerabilities, security operations leaders on the customer side reading against the SLA expectations in their contract. | Generated from findings management as a sanitised summary that aggregates open finding counts by severity, by SLA tier, and by remediation state. Raw finding records are never released; the aggregated view is. AI report generation composes the customer-audience summary from the live record so the figure released to a customer matches the figure on the internal engagement at release time. |
| Architecture and data-flow overview | Customer reviewers in regulated industries (financial services, healthcare, defence, public sector) reading against shared-responsibility models, prospects reading against contractual subprocessor disclosure obligations. | A redacted architecture and data-flow diagram with high-level component naming, region disclosure, and subprocessor identifiers. Sensitive internal naming, vendor-specific routing, and infrastructure secrets are redacted at capture rather than at release. Hold the diagram as a versioned document object so the customer release reads against the same artefact the security team read against on the engagement. |
| Subprocessor list and data residency map | Customer reviewers reading against GDPR Article 28, customers reading against contractual subprocessor change notification windows, regulators reading the supply-chain disclosure through the customer relationship. | Maintain the subprocessor list and the data residency map as live documents on the workspace. When a new subprocessor is added or a region is changed, the change-notification workflow lands on the engagement so contractually obligated customer notifications fire on the documented cadence rather than on a discovered-after-the-fact basis. |
| Security policy excerpts and control mapping | Customer reviewers asking for evidence on a specific control area (access management, encryption, change management, vendor management, incident response), GRC reviewers building the cross-customer control mapping that feeds their TPRM register. | Hold the canonical policy versions in document management with the policy effective date, the named owner, and the review cadence. The customer-facing release is an excerpt or summary that maps the policy to the requested control area without releasing the full internal policy text. The control mapping feeds the customer questionnaire response workflow so the same evidence answers SIG, CAIQ, and bespoke procurement forms. |
| Incident-response readiness attestation | Customer reviewers asking for evidence of incident response readiness, customer security operations leaders reading against the contractual notification windows in MSAs and DPAs, regulators reading the incident readiness through the customer relationship. | A short attestation that captures the IR programme cadence (last tabletop date, last IR plan review, last IR test), the named programme owner, and the attestation date. Reference the underlying engagements that hold the operational evidence rather than releasing the operational record itself. |
Six failure modes that quietly break customer evidence rooms
Most evidence-room failures look like sensible defaults: forward the attachment, send the report, share the slide. The cost arrives months later as a stale artefact in circulation, an untracked release without an NDA, a customer-facing figure that does not match the internal record, or a contractually obligated notification that quietly missed.
Evidence lives in a shared inbox and a SharePoint folder
Customer security reviewers email a request, an SE forwards it to security, security replies with an attachment from a SharePoint folder, the attachment is whatever was uploaded last. There is no record of who released what to whom on which date, no version control on the evidence, no audit trail when a customer claims a stale artefact, and no reusability across the next reviewer asking the same question. The fix is making every customer evidence release a structured action on a customer engagement record so the chain of custody is reconstructable.
Stale artefacts circulate after expiry
A SOC 2 report from twenty months ago is still being shared because nobody noticed the observation period closed. An ISO 27001 certificate from a prior issuance year is still pinned in the trust folder. Customers consume the stale artefact and discover the gap during their own audit. The fix is stamping every evidence artefact with an effective date and an expiry date at capture so renewal triggers a re-release rather than a discovered staleness.
Evidence release lacks NDA gating
A SOC 2 report is sent to a reviewer who never countersigned the NDA, then forwarded internally on the customer side, then forwarded externally to a procurement consultant. The release was untracked because the gate was a verbal agreement on a sales call. The fix is enforcing the NDA as a structured prerequisite on the engagement: no countersigned NDA on file, no release.
Reviewer asks the same question every quarter
A customer security team asks for the same control evidence at every renewal cycle because the answer is not pinned to anything they can return to. The security team rebuilds the answer from scratch each time. The fix is a maintained customer engagement record that holds the prior release history and a customer-facing portal view that the reviewer can return to between renewals so the security team does not re-author the same packaging.
Contractual notification commitments quietly drift
The MSA promises 30-day notice on subprocessor changes and the DPA promises advance disclosure on data residency shifts. The subprocessor list updates internally; the customer-facing notifications never fire because nobody owns the trigger. The fix is binding the subprocessor list and the data residency map to a notification workflow on the customer engagement so the contractually obligated outbound notice fires on the documented cadence.
Internal evidence and customer-facing evidence diverge
Findings management says open critical count is twelve; the customer-facing summary says nine because someone manually edited the slide three days before release. The customer asks how the figure was produced and the team has no clean answer. The fix is composing the customer-facing summary from the live record at release time rather than maintaining a parallel deck the customer reads against.
Six fields every release decision has to record
A defensible release decision is six concrete fields on the customer engagement, not a verbal agreement on a sales call. The fields make the disclosure chronology reconstructable when an internal audit, a regulator, or a litigant asks how the company shared what, when, and to whom.
Requester identity and reviewer scope
The named reviewer on the customer side, the customer or prospect organisation, the deal stage (RFP, security review, contract negotiation, renewal, post-incident review, regulator-driven assessment), and the scope of the request (full SOC 2, attestation only, control-specific excerpt, vulnerability summary, architecture diagram, subprocessor list). The scope is what governs which artefacts are eligible for release and at which redaction level.
Legal preconditions
The countersigned NDA on file (with the NDA reference, the effective date, and the named signatories on both sides), any applicable regulator carve-outs (defence, public-sector, healthcare, financial-services), any contractual restriction on onward sharing, and the named approver on the security side authorised to release at this scope. No NDA, no release.
Artefact list and redaction level
The artefacts the determination authorises (SOC 2 Type 2 report version 2024 H2, ISO 27001 certificate from issuing body X dated Y, pentest attestation from firm Z dated W, vulnerability summary at the aggregate-by-severity level, architecture diagram at the redacted-component level, subprocessor list current as of date V), the redaction level applied per artefact, and the watermarking scheme used on each export.
Release channel and access scope
The release channel (branded client portal access scoped to the named reviewer, watermarked download via signed URL, NDA-gated email attachment, in-person review at a structured walkthrough), the duration of access where applicable, and the named owner on the security side responsible for revoking access when the deal stage closes or the request resolves. Access without a revocation owner is access that drifts.
Outbound communications log
Every outbound communication tied to the release (the NDA countersignature exchange, the artefact transmittal cover note, the follow-up clarification responses, the access-revocation notification at deal close) lands on the engagement with the named author, the timestamp, and the artefact reference cited. The communications log is what reconstructs the disclosure chronology when an internal audit, a regulator, or a litigant asks how the company shared what, when, and to whom.
Re-evaluation triggers and chronology
Re-evaluation triggers (SOC 2 renewal cycle, ISO 27001 surveillance, pentest attestation rollover, subprocessor list change, data residency shift, material incident requiring updated disclosure, contractual notification clock), the cadence on which the customer-facing record is re-released, and the chronology of releases stitched against the underlying artefact versions. Each re-release is a fresh determination on the engagement; nothing is overwritten so the chronology stays reconstructable.
Eight queues the engagement runs in parallel during the active relationship cycle
During an active customer relationship the engagement runs eight queues concurrently. Each queue has a named owner, a documented cadence, and an unresolved-item escalation rule so releases, NDA chases, and access revocations do not fall behind the cadence between weekly reads.
- Open customer-evidence-request queue with the requester organisation, the reviewer name, the scope, the deal stage, and the contractual deadline.
- NDA countersignature queue with each reviewer who has not yet countersigned, the named owner on the security side chasing the countersignature, and the gating effect on outbound release.
- Pending release-decision queue with each requested artefact awaiting the named approver, the redaction level decision, and the release channel selection.
- Active release queue with each in-flight transmittal, the watermarking and signed-URL scheme used, the named recipient, and the access expiry date.
- Stale-artefact watch queue with every released artefact whose underlying source (SOC 2 observation period, ISO 27001 certificate, pentest attestation, subprocessor list version) is approaching expiry so a re-release is triggered before the customer consumes a stale artefact.
- Subprocessor and data-residency change queue with each change pending contractual notification, the named customer engagement records affected, and the notification cadence promised in the MSA or DPA.
- Reviewer follow-up queue with every clarification a reviewer is waiting on, the named author, and the response deadline.
- Access-revocation queue with each access scope expiring or eligible for revocation as deal stages close, with the named security-side owner who closes the loop and the timestamp of the revocation.
How the customer security evidence room runs in SecPortal
The evidence room rides on the same feature surfaces the rest of the security programme already uses. The customer relationship opens as an engagement on the workspace, every artefact lives in document management, the branded client portal hosts reviewer access, findings management feeds the customer-facing vulnerability summary, the activity log captures every release and revocation, AI report generation composes the customer-audience artefacts from the live record, and team management role-based access scopes who can release what.
Customer relationship as engagement
Each customer or prospect under active security review opens on the engagement record with the named requester, the deal stage, the contractual notification cadence, and the release-decision history. Every release lands on the engagement so the chain of disclosures stays queryable.
Artefacts in document management
Document management holds the SOC 2 report, the ISO 27001 certificate, the pentest attestation, the architecture diagram, the subprocessor list, the policy excerpts, and the IR readiness attestation as versioned objects with effective dates, expiry dates, and named owners.
Branded portal for reviewer access
The branded client portal on a tenant subdomain hosts customer-reviewer access to released artefacts. Each reviewer sees only the scope authorised on the engagement so the release surface is bounded rather than open to broadcast download.
Vulnerability summary from live findings
Findings management feeds the aggregate-by-severity, aggregate-by-SLA-tier, and aggregate-by-remediation-state summary at release time so the customer-facing figure matches the internal engagement record at the moment of release.
RBAC across release approvers
Team management scopes engagement access to the named release approver, the redaction owner, the named transmittal author, and the access-revocation owner. Sensitive artefacts route through the approver before reaching a customer-facing channel.
MFA on sensitive evidence
MFA enforcement on the workspace and the portal protects the evidence-room surface where SOC 2 reports, pentest attestations, and policy artefacts are accessed. A reviewer with credentials but without the second factor cannot reach the gated artefact.
AI release composition
AI report generation composes the customer-audience vulnerability summary, the IR readiness attestation, the control-mapped policy excerpts, and the executive overview from the live engagement and findings records before the named approver reviews and authorises release.
Notifications surface release work
Notifications push pending NDA countersignatures, pending release approvals, and pending access revocations to the named owners on a documented cadence so the queues do not silently fall behind.
Activity log evidence chain
The activity log captures every NDA exchange, release decision, transmittal, access scope change, and revocation event with timestamp and user attribution. The CSV export is the inquiry-response evidence chain when a customer audit, a regulator-driven assessment, or an internal review reads back the disclosure trail.
Five reads the evidence-room engagement actually drives
The reads that drive evidence-room work are not the static trust-page snapshot. They are the live views the deal desk, the security reviewer, the named release approver, and the legal counsel use between renewals.
Open release-decision queue
Every pending release with the requester, the artefact list, the redaction level, the named approver, and the contractual deadline. The view the security operations leader reads against the calendar.
NDA register read
Every reviewer with the NDA reference, effective date, and gating effect on outbound release. The view the legal counsel and the deal desk read to confirm releases sit on executed agreements.
Stale-artefact watch
Every released artefact approaching expiry with the affected customers, the renewal trigger, and the re-release plan. The view the GRC team reads so customers do not consume stale evidence.
Subprocessor change notifications
Every pending subprocessor or data-residency change with the affected customer engagements, the contractually obligated notification cadence, and the named author for the outbound notice. The view the privacy and procurement teams read together.
Activity log export
Every state change across NDA exchange, release decision, transmittal, access scope change, and revocation with timestamp and user attribution. The CSV export is the evidence chain the customer audit and the regulator-driven assessment read against.
What auditors and customer-driven assessments expect
Customer evidence work shows up in audit reads whenever an external assessor reviews the operator's third-party risk posture, the operator's information transfer controls, or the operator's subprocessor management. The frameworks below all expect evidence that covers the artefact register, the disclosure log, the NDA gating, the watermarking practice, and the access-revocation chronology.
| Framework | What the audit expects |
|---|---|
| SOC 2 Trust Services Criteria | CC2.x (communication and information, including external communication of objectives), CC6.1 (logical access security to systems and information), CC6.6 (transmission of information internally and externally), CC7.1 (the entity uses detection and monitoring procedures to identify changes that could result in introduction of new vulnerabilities), and CC9.x (risk mitigation, including third-party communication) all read against the customer-evidence-room workflow. The disclosure log, the NDA register, the redaction decisions, the watermarking practice, and the access-revocation chronology are the SOC 2 Type 2 evidence chain. |
| ISO 27001:2022 | Annex A 5.7 (threat intelligence, where customer-shared advisories close the loop with internal CTI), 5.10 (acceptable use of information), 5.13 (labelling of information), 5.14 (information transfer, the explicit control the workflow produces evidence against), 5.15 (access control), 5.34 (privacy and protection of PII), 6.7 (remote working where reviewer access is remote), 8.10 (information deletion where revoked access deletes), 8.11 (data masking, the redaction practice), and 8.12 (data leakage prevention) all read against the workflow. |
| GDPR (EU 2016/679) | Article 28 (processor obligations including subprocessor disclosure and notification) and Article 32 (security of processing) read against the subprocessor list, the data residency map, and the contractually obligated change notification cadence the workflow operates on. The named subprocessor change history, the notification log per customer, and the activity log entries showing the notification was sent on the documented cadence are the lawful-basis evidence. |
| PCI DSS v4.0 | Requirement 12.8 (manage third-party service provider relationships) and 12.9 (incident response and communication with customers) read against the customer-evidence-room when the workspace operator is itself a service provider. The NDA register, the disclosure log, and the incident-readiness attestation are the QSA evidence chain. |
| NIST SP 800-53 Rev. 5 | CA-2 (control assessments), CA-3 (information exchange, particularly the formal agreement between connected systems and the parties exchanging information), CA-6 (authorisations), PM-30 (supply chain risk management strategy), SR-2 (supply chain risk management plan), and SR-3 (supply chain controls and processes) read against the workflow when the workspace operator is shared with a federal customer relationship. |
| NIS2 Directive and DORA (where the operator is in scope) | NIS2 Article 21 (cybersecurity risk-management measures, particularly the supply chain security obligations) and DORA Article 28 (general principles for ICT third-party risk) read against the customer-evidence-room when the operator falls within either regime. The subprocessor list, the data residency map, the contractual notification cadence, and the disclosure chronology are the supervisory-authority evidence the regulator expects. |
Where the evidence room sits in the rest of the security operating model
The customer security evidence room is upstream of the per-questionnaire response, the internal audit-evidence retention discipline, the cyber-insurance evidence pack, and the control-mapping crosswalks. The artefacts the evidence room maintains feed every adjacent workflow so the same SOC 2 report, the same ISO 27001 certificate, the same pentest attestation, and the same vulnerability summary answer many requests without re-authoring.
Upstream and adjacent
The compliance backbone that produces the SOC 2 evidence runs on the compliance audits workflow, the internal audit-evidence retention discipline runs on the audit evidence retention workflow, and the control-mapping crosswalks that turn one canonical control into many framework citations run on the control mapping crosswalks workflow.
Downstream and reporting
The per-questionnaire response that drafts answers from the canonical evidence library runs on the vendor security questionnaire response workflow, the cyber-insurance-specific evidence pack 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 customer security evidence room is operational. The surrounding long-form guides explain the underlying frameworks, the disclosure cadences, and the audit operating model 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 operating model, the third-party vendor risk assessment guide for the inverse view (how the company runs TPRM on its own suppliers), and the security compliance automation guide for the broader operating-model context. The framework references that mandate the evidence-room evidence include the SOC 2 framework page, the ISO 27001 framework page, the GDPR framework page, the NIST SP 800-53 framework page, the PCI DSS framework page, and the DORA framework page.
Buyer and operator pairing
The customer security evidence room is the workflow internal security teams run as the customer-facing evidence pipeline, GRC and compliance teams run as the artefact register and disclosure log, AppSec teams feed with the vulnerability summary and remediation status, CISOs read as the customer-relationship evidence trail at the quarterly review, and security operations leaders run as the queue execution discipline that prevents the evidence room from drifting back into a shared inbox.
What a good customer security evidence room feels like
Every artefact has a version
No artefact lives only on a slide deck. The SOC 2 report, the ISO 27001 certificate, the pentest attestation, the architecture diagram, and the subprocessor list all live as versioned objects with effective and expiry dates.
Every release has an NDA gate
No countersigned NDA, no release. The reviewer identity, the NDA reference, and the named approver gate the release rather than a verbal agreement on a sales call.
Every release watermarks at export
Watermark-on-export with the requester identifier and the release date so circulation outside the original recipient is traceable. Access scopes carry an expiry date and a named revocation owner.
Audit reads from one record
The artefact register, the NDA log, the disclosure log, the watermarking practice, and the access-revocation chronology all read from the same engagement. SOC 2 examiners, ISO 27001 auditors, GDPR-aware customer reviewers, and customer-driven assessors get the evidence as a query rather than a multi-week reconciliation sprint.
The customer security evidence room is the structured workflow the security operations leader, the GRC team, the AppSec lead, the legal counsel, and the deal desk all read against. Run it on one engagement record so every NDA, every release, every watermark, every access scope, and every revocation lives on a single trail rather than scattered across email attachments, SharePoint folders, and verbal agreements on sales calls.
Frequently asked questions about customer security evidence rooms
What is a customer security evidence room?
A customer security evidence room is the operational workflow B2B SaaS security teams use to package, release, and revoke security evidence to customer reviewers, prospects under security review, regulator-driven assessments riding through customer relationships, and renewal-cycle TPRM reviews. The room is not a single static page; it is the maintained discipline that holds every artefact (SOC 2 report, ISO 27001 certificate, pentest attestation, vulnerability summary, architecture diagram, subprocessor list, policy excerpts, IR readiness attestation), the disclosure log, the NDA register, the watermarking practice, the access-revocation chronology, and the contractually obligated notification cadence on a structured engagement record. The room reduces per-questionnaire reactive load and turns a recurring sales-blocking exercise into a repeatable workflow.
How is this different from responding to a vendor security questionnaire?
A vendor security questionnaire is a written form (CAIQ, SIG, ISO 27001 supplier review) that a customer sends; the response is bespoke per questionnaire. A customer security evidence room is the upstream artefact discipline that feeds those questionnaire responses with consistent, current evidence and that handles the broader release surface (NDA-gated SOC 2 access, branded portal walkthrough, subprocessor change notifications, attestation letter releases, regulator-driven asks). Run them together: the evidence room holds the canonical artefacts; the vendor questionnaire response workflow drafts the answers from those artefacts. The evidence room reduces the reactive load on the questionnaire workflow because the same artefacts answer many questionnaires.
How does the workflow keep the customer-facing summary in sync with internal findings?
The customer-facing vulnerability summary is generated from findings management at release time rather than maintained as a parallel deck. AI report generation composes the aggregate-by-severity, aggregate-by-SLA-tier, and aggregate-by-remediation-state view from the live record so the figure released to a customer matches the figure on the internal engagement at the moment of release. When the customer asks how the figure was produced, the team can point to the engagement record and the activity log entry that captured the release.
How does the workflow handle stale artefacts after expiry?
Every released artefact carries an effective date and an expiry date stamped at capture. SOC 2 reports carry the observation period close date; ISO 27001 certificates carry the certificate expiry date; pentest attestations carry the testing-window close date; subprocessor lists carry a current-as-of date. The stale-artefact watch queue surfaces every artefact approaching expiry so a re-release is triggered before the customer consumes a stale copy. The activity log captures the re-release event so the chronology of artefact versions held by each customer is reconstructable.
How does the workflow gate access with NDAs and watermarking?
The workflow treats the countersigned NDA as a structured prerequisite on the customer engagement. No countersigned NDA on file, no release. The NDA reference, the effective date, and the named signatories on both sides are captured before the artefact moves through the release channel. Watermark-on-export is applied per recipient at the moment of release with the requester identifier and the release date so circulation outside the original recipient is traceable. Access scopes carry an expiry date and a named security-side owner responsible for revocation when the deal stage closes.
How does the workflow handle subprocessor change notifications?
The subprocessor list and the data residency map live as maintained documents on the workspace. When a subprocessor is added, removed, or repositioned, the change lands on the customer engagement records affected and the notification cadence promised in the MSA or DPA fires through the workflow. Outbound notifications log on the engagement with the named author, the timestamp, and the affected customer so the contractually obligated notice trail is reconstructable. Customers reading against GDPR Article 28 obligations receive the notice on the documented cadence rather than on a discovered-after-the-fact basis.
Does SecPortal sign customer NDAs on my behalf?
No. SecPortal holds the operational record of the workflow. The named programme owner, in coordination with legal counsel, signs the customer NDAs and DPAs through the company's normal contracting process. SecPortal stores the countersigned artefacts in document management with reference and effective date so the gating logic on release can read against the executed agreement rather than against an assumed one.
How long does a customer evidence engagement stay open?
The engagement is typically structured per customer relationship rather than per release. A new prospect under active security review opens an engagement that holds every release, every NDA exchange, every clarification, and every access scope. When the deal closes (won, lost, or paused) the engagement remains open as the maintained customer record so the next renewal, the next regulator-driven assessment, or the next material event reads against the prior history. The activity log captures the chronology across the entire customer relationship so the disclosure trail stays continuous.
How does AI report generation help the evidence room?
AI report generation composes the customer-facing vulnerability summary, the IR-readiness attestation, the control-mapped policy excerpts, and the executive overview from the live engagement and findings records at release time. The team reviews and approves the composition before release; the AI does not auto-release. Because the composition reads from the same record an internal audit reads, the released artefact and the internal record never diverge. When a customer asks how a figure was produced, the answer is one query against the engagement.
What if a customer wants raw findings rather than a summary?
Most customer security reviews accept aggregate-by-severity summaries, attestation letters, and control-mapped policy excerpts. When a regulator-driven ask, a high-stakes contract negotiation, or a post-incident review demands deeper detail, the release decision can authorise a redacted finding-level export with watermarking and a short access window. The decision lives on the engagement with the named approver, the redaction scope, and the access-revocation owner so the deeper release does not erode the discipline of the standard release.
How it works in SecPortal
A streamlined workflow from start to finish.
Open every customer or prospect under active security review as an engagement
A customer security review starts the moment a reviewer asks for the first artefact. Open the relationship as an engagement on the customer or prospect record with the named requester on the customer side, the deal stage (RFP, security review, contract negotiation, renewal, post-incident review, regulator-driven assessment), the contractual notification cadence promised in the MSA or DPA, the named programme owner on the security side, and the release-decision history. Every release the workflow makes lands on the engagement so the chain of disclosures stays queryable rather than scattered across forwarded attachments and shared-inbox threads.
Hold canonical artefacts in document management with effective and expiry dates
The evidence room holds a small number of high-trust artefacts as canonical, versioned objects on the workspace: the SOC 2 Type 2 report with the observation period and the named auditor, the ISO 27001 certificate with the issuing body and the certificate expiry, the pentest attestation letter with the testing window and the testing firm, the redacted architecture diagram with the version date, the subprocessor list with the current-as-of date, the data residency map, the policy excerpts with the effective dates, and the IR readiness attestation. Every artefact carries an effective date and an expiry date stamped at capture so the stale-artefact watch queue can surface renewals before customers consume out-of-date evidence.
Gate every release with the countersigned NDA, the named approver, and the redaction level
A defensible release decision is six concrete fields on the customer engagement: the requester identity and reviewer scope, the legal preconditions (countersigned NDA on file with reference and effective date, regulator carve-outs, contractual restrictions, named approver), the artefact list and redaction level, the release channel (branded portal access, watermarked download, NDA-gated email, in-person walkthrough), the outbound communications log, and the re-evaluation triggers. No countersigned NDA, no release. No named approver, no transmittal. Watermark-on-export with the requester identifier and the release date so circulation outside the original recipient is traceable.
Compose customer-facing summaries from the live record at release time
The customer-facing vulnerability summary, the IR readiness attestation, and the control-mapped policy excerpts are composed from findings management, the engagement record, and document management at release time rather than maintained as a parallel deck. AI report generation drafts the aggregate-by-severity, aggregate-by-SLA-tier, and aggregate-by-remediation-state view; the named approver reviews and authorises release. The released figure matches the figure on the internal engagement at the moment of release so the customer-facing record and the internal record never diverge under questioning.
Operate parallel queues for releases, NDA chases, stale artefacts, and access revocations
During an active relationship cycle the engagement runs eight queues concurrently: the open release-decision queue, the NDA countersignature queue, the active release queue, the stale-artefact watch queue, the subprocessor and data-residency change queue, the reviewer follow-up queue, the access-revocation queue, and the customer-evidence-request queue. Each queue has a named owner, a documented cadence (often weekly with a daily pulse during active deal-stages), and an unresolved-item escalation rule so releases, NDA chases, and access revocations do not fall behind the cadence between weekly reads.
Fire contractual notifications on the documented cadence rather than after the fact
Subprocessor list changes, data residency shifts, material incident disclosures, and renewed certifications all trigger contractually obligated outbound notifications. The MSA promises 30-day notice on subprocessor changes; the DPA promises advance disclosure on data residency shifts. The workflow binds each change to the affected customer engagements so the notification fires through the documented channel with the named author, the timestamp, and the artefact reference cited. Customers reading against GDPR Article 28 obligations or against MSA notice clauses receive the notice on the documented cadence rather than on a discovered-after-the-fact basis.
Revoke access at deal close and capture the disclosure trail for the next cycle
Access scopes carry an expiry date and a named security-side owner responsible for revocation when the deal stage closes (won, lost, paused) or when the request resolves. The activity log captures every NDA exchange, release decision, transmittal, access scope change, and revocation event with timestamp and user attribution. The CSV export is the inquiry-response evidence chain when a customer audit, a regulator-driven assessment, or an internal review reads back the disclosure trail. The engagement remains open as the maintained customer record so the next renewal, the next regulator-driven assessment, or the next material event reads against the prior history.
Features that power this workflow
Orchestrate every security engagement from start to finish
Document management for every security engagement
Your brand. Your portal. Your clients love it.
Vulnerability management software that tracks every finding
Collaborate across your entire team
Multi-factor authentication on every workspace
AI-powered reports in seconds, not days
Notifications and alerts for the people who carry the work
Every action recorded across the workspace
Compliance tracking without a full GRC platform
Run the customer security evidence room on one engagement record
NDA-gated SOC 2, ISO 27001, pentest attestation, vulnerability summary, and subprocessor releases on a recorded chain of custody. Reduce per-questionnaire reactive load. Start free.
No credit card required. Free plan available forever.