Finding comments and collaboration
on the same record as the work
Per-finding comments scoped to the tenant, attributed to an immutable author email, written to the activity log, and visible to both workspace members and client portal users. Triage, escalation, exception rationale, and retest context land on the finding rather than in email.
No credit card required. Free plan available forever.
A per-finding conversation surface your auditor, your engineer, and your client can all read
Security findings rarely close themselves. Behind every status change is a discussion: a reviewer translating a scanner result into application context, an engineer asking for a smaller repro, a client pushing back on a severity, a senior accountable owner asking whether the proposed compensating control is acceptable, an auditor asking why a finding moved to accepted risk. When those conversations live in email, chat threads, ticket comments, and meeting notes, the record on the finding never explains itself. SecPortal keeps the conversation on the finding so the next reader does not have to reconstruct it from memory.
Per-finding comments are part of the platform by default for every workspace. The comments table is anchored to the parent finding, scoped to the tenant by Supabase row-level security, attributed to an immutable author email, and written into the same activity log every other workspace action lands on. The same comment thread is visible to workspace members through the dashboard finding view and to the client portal user through the client portal finding view, so the workspace and the portal share one conversation rather than two timelines that have to be reconciled.
Four fields, one durable record per comment
Each comment is a small, durable record. The shape is intentionally minimal so the conversation reads as a record rather than as ephemeral chat. The finding id anchors the thread, the author email survives any later identity change through a database trigger, the content is plain text, and the created_at timestamp anchors the comment on the same clock every other workspace event runs on.
finding_id
Every comment is anchored to the finding it discusses. A conversation never floats free of the record it explains, so a reader who lands on a finding from an audit query, a scanner export, or a remediation review sees the discussion as part of the record rather than archaeological context elsewhere.
user_id and author_email
The comment carries the authenticated user id and the author email. The email is set by a database trigger on insert and update, so the author identity stays immutable even if a workspace email later changes. Attribution survives reorganisation, departures, and rename events.
content
A plain-text comment body. The thread is intentionally text first, so the conversation reads like a record rather than a chat scrollback. The contents stay on the engagement and survive any retention or export window that applies to the parent finding.
created_at
A server-side timestamp that anchors the comment on the same timeline as scanner findings, remediation status changes, and document uploads. Auditors and incident reviewers read every comment against the same clock the rest of the record runs on.
What lands on the comment thread
The thread is for the conversation that explains why the finding looks the way it does today. It is not a chat channel for unrelated work, and it is not a place to store evidence files. Comments answer the question another reader is going to ask the record after the original reviewer has moved on.
A workspace member triages a scanner result
A reviewer opens an authenticated scan finding, confirms the affected route, and posts a comment explaining the credentialed-session repro. The next person on triage reads the prior judgement on the same record before deciding whether to close, escalate, or hand off to engineering.
A client portal user pushes back on a finding
A portal user disputes a severity, asks for clarification, or asks for a different remediation path. The comment lands on the finding, the workspace user replies on the same record, and the dispute is part of the audit trail rather than an email thread that the next reviewer cannot find.
An engineer asks for a smaller reproduction
The owning engineer reads the finding, asks for a reduced repro or a specific payload, and the AppSec reviewer answers on the comment thread. The exchange stays attached to the finding so the next engineer who picks up the queue inherits the answer rather than restarting the question.
A reviewer documents an off-record decision
Conversations that decided the finding direction (severity, ownership, deferral, retest scope) get written back to the comment thread so the record explains why it landed where it did. The decision is anchored to the work rather than to a meeting nobody can replay.
Properties that keep the conversation defensible
Comments are only useful if they are durable, scoped, attributed, and audit-readable. SecPortal applies the same properties to every comment, so the conversation surface is consistent across workspaces, engagements, and tenants.
Per-finding scope
Comments are scoped to a single finding rather than to a thread or an engagement-wide channel. The conversation never drifts into a separate venue that disagrees with the record. The finding is the only place the discussion lives.
Tenant-isolated by row-level security
Supabase row-level security on the comments table only returns rows the reader has access to under the workspace and the engagement. Workspace members read the workspace conversation, client portal users read only the conversation on findings they have access to, and cross-tenant reads are blocked at the database boundary.
Workspace member and client portal user threads
Workspace members comment from the dashboard finding view. Client portal users comment from the portal finding view when their engagement is published. Both write into the same comments table and surface on the same finding, so the workspace and the portal share one conversation rather than two timelines that have to be reconciled.
Author-controlled edit and delete
A comment author can edit or delete their own comment. Workspace consultants can delete comments inside their workspace if a post needs to be removed for an evidence or compliance reason. Every change writes an immutable activity log entry so the deletion itself stays on the audit trail.
Visible on the activity log
Each new comment fans out as a comment.created action on the workspace activity log, with the actor, the finding title, and a timestamp. The activity log feed reads the comment in context next to status changes, document uploads, and severity overrides on the same finding.
Notification fan-out to the right inbox
New comments trigger the same notification fan-out that other workspace events use, so reviewers and engagement leads see the comment on their in-app notifications inbox without polling the finding view. The bell and the timeline read against the same source so the live signal and the record never disagree.
What auditors and incident reviewers read in the thread
Auditors reading ISO 27001 Annex A 8.15 (logging), SOC 2 CC7.1 and CC7.4, and PCI DSS Requirement 10 read activity logs and finding records to evidence operating effectiveness rather than narrative claims. Per-finding comments sit on the same timeline so the rationale behind a decision is recoverable on the same record as the decision itself.
- Show the auditor why a finding moved to accepted_risk and who signed off, with the conversation that produced the decision on the same record
- Reconstruct the triage path for a contested finding when a reviewer rotates off and a successor takes over the record
- Evidence the operating effectiveness of an exception process by showing the discussion that preceded each suppression alongside the structured override
- Prove that a customer-reported issue was answered, escalated, or resolved by reading the finding comments against the timestamp on the report
- Demonstrate segregation of duties between the testers, the reviewers, and the approvers by reading the actor on each comment alongside the role change events on the same workspace
- Trace the rationale behind a severity recalibration when scanner default severity did not match real exposure, without trusting reconstruction from chat scrollback
Handoff surfaces the comment thread covers
Security work moves between people. Each handoff is a moment where the record on the finding is the only inheritance the next reader gets. The comment thread is the surface where the handoff context lives, so the next reviewer, the owning engineer, the client portal user, or the retester picks up the work with the prior decisions intact.
Workspace to client portal handoff
A workspace consultant publishes the engagement to the client portal and the client portal user reads the finding alongside the comment thread. Questions and pushback land on the same record on both sides, so the client question and the consultant answer share one timeline rather than living in email.
AppSec to engineering handoff
An AppSec reviewer adds the comment that explains why a scanner finding matters in the specific application context. The owning engineer reads the comment as part of the remediation brief and answers any clarifying question on the same record. The translation work survives the handoff rather than restarting on the next ticket.
Reviewer rotation handoff
A reviewer rotates off the engagement and a successor takes over the finding queue. The comment thread is the single inheritance surface that explains where each finding landed, what was open, and what the contested decisions were. The new reviewer reads the record once instead of reassembling the history.
Retest handoff
A finding moves to resolved and the retester needs to know what to retest. The comment thread explains the agreed verification scope, the parts that were deferred, and the regression risk to watch. The retest decision sits next to the original triage decision rather than in a separate document.
Who can do what
Comment authority follows the workspace team-management RBAC and the comments table row-level security policy. The boundary between a workspace member, a workspace viewer, an admin, and a client portal user is enforced at the database, not in the UI.
Workspace owners and admins
Comment freely on any finding in the workspace, edit and delete their own comments, and have authority to delete other comments where evidence policy requires removal. The activity log records every action so removal stays on the audit trail.
Workspace members
Comment on findings inside engagements they have access to under their RBAC role. Edit and delete their own comments. The comment ownership is enforced by the comments row-level security policy at the database boundary.
Workspace viewers
Read comments on findings they have access to but cannot post or modify. The viewer role is the audit and observer profile that reads the work without writing to it.
Client portal users
Read and post comments on findings inside engagements the client has access to. Comments from the portal write to the same comments table the workspace uses, so the conversation reads as one thread per finding regardless of which side posted it.
Adjacent surfaces the comment thread connects to
Per-finding comments are one part of the workspace conversation surface. Engagement-wide messages, document attachments, and structured finding overrides each carry a different kind of decision context. The finding record is the integration point so the four surfaces read as one record on the engagement.
Engagement messages
Per-engagement messages run alongside per-finding comments. The messages table covers conversation that applies across multiple findings (scope clarification, scheduling, escalation routing), while the comments table covers conversation tied to a specific finding. Both surface on the engagement view so the engagement reads as one record.
Document attachments
When a comment references evidence (screenshot, request/response, scanner export), the artefact lands on the document store attached to the same finding. The conversation and the evidence share one parent record, so the audit chain of custody is recoverable from the finding rather than from a folder named after a date.
Finding overrides
When a comment thread decides a suppression (false positive, accepted risk, severity recalibration), the structured override carries the decision. The comment explains why, the override carries the policy effect, and the activity log carries the timestamp. The three surfaces share one finding record.
Where comments fit in your security programme
Comments are the connective tissue between the structured record on a finding and the human judgement that decided where the record sits today. They plug into findings management as the conversation surface attached to every finding lifecycle event, into notifications and alerts as the trigger for the per-user inbox fan-out, and into retesting workflows as the documented rationale that explains every resolved-to-verified transition rather than collapsing the decision into a single timestamp.
For frameworks that name a logging or evidence control directly, comments sit on the same timeline the rest of the record runs on: ISO 27001 Annex A 8.15 expects logging of security-relevant user actions; SOC 2 CC7.1 expects monitoring of system component changes including the controls that surround them; and PCI DSS Requirement 10 expects logging of access to system components. Workspace-scoped comments satisfy the platform-level expectation that the rationale behind security-finding decisions is recoverable on the same record as the decisions themselves.
For the operational workflows that the comment thread serves, the discussion attaches directly to the work: comments on the findings inside vulnerability finding intake and finding translation into developer language keep the translation rationale on the record, comments on the findings inside vulnerability acceptance and exception management keep the exception rationale on the record, and comments on the findings inside fix verification keep the verification rationale on the record.
Honest scope: SecPortal does not synchronise the comment thread to external collaboration platforms (no Slack, Microsoft Teams, Jira, ServiceNow, Linear, or Azure DevOps integration on the comment surface). The conversation lives on the finding inside the workspace and the portal. When external tools own the engineering ticket, the finding URL is the cross-reference and the comment thread is the security-side record.
Per-finding comments are the finding-scoped half of the workspace conversation surface. The engagement-scoped half is engagement messaging, which covers the scope, the test-window agreement, the schedule, the escalation, and the closing handover that apply across many findings on the same engagement. Both surfaces write into separate tables, both attach to the same engagement record, and both share the same workspace activity log timeline, so the engagement view reads as one record even when the conversation moves between finding-specific and engagement-wide context.
Per-finding comments answer the retrospective question (why did this finding land where it did, who said what when), while the workspace global search palette answers the prospective question (where is the finding sitting today). Both views read against the same workspace record, so the comment thread and the search index never disagree about what was said or where the finding lives now.
Keep the conversation on the finding
Every comment carries the actor, the timestamp, and the parent finding. Workspace and portal share one thread per finding. The next reviewer reads the rationale instead of reconstructing it.
No credit card required. Free plan available forever.