Engagement messaging
on the same record as the engagement
Per-engagement chat 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. Scope, schedule, escalation, and handover land on the engagement rather than in email.
No credit card required. Free plan available forever.
A per-engagement chat surface that lives on the same record as the work
Security engagements rarely run silent. Scope confirmations, test-window agreements, credential handovers, stop-test signals, scheduling pivots, mid-engagement updates, closing handovers, retest agreements: every engagement carries a running conversation that the record on the engagement has to explain when the next reviewer or the auditor opens it. When that conversation lives in email, ad-hoc chat, or meeting notes, the engagement record cannot stand on its own. SecPortal keeps the chat on the engagement so the next reader does not have to reconstruct it from somewhere else.
Per-engagement messages are part of the platform by default for every workspace. The messages table is anchored to the parent engagement, 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 chat thread is visible to workspace members through the dashboard engagement view and to the client portal user through the client portal engagement view, so the workspace and the portal share one conversation rather than two timelines that have to be reconciled.
Five fields, one durable record per message
Each message is a small, durable record. The shape is intentionally minimal so the chat reads as a record rather than as ephemeral scrollback. The engagement id anchors the thread, the author email survives any later identity change through a database trigger, the content is plain text, and the created and updated timestamps anchor the message on the same clock every other workspace event runs on.
engagement_id
Every message is anchored to the engagement it belongs to. The conversation lives on the parent engagement record, so when a reader opens the engagement view weeks or months later, the chat history is part of the record rather than a separate inbox that needs reconciling against the work.
user_id and author_email
Each message 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, role changes, and rename events.
content
A plain-text message body. The thread is intentionally text first, so the chat reads like a record rather than ephemeral scrollback. Messages stay attached to the engagement and survive any retention or export window the engagement runs on.
created_at and updated_at
A server-side created timestamp anchors the message on the same clock the rest of the workspace runs on. An updated timestamp covers in-place edits, so a later reader can tell that a message was revised after it was first posted rather than treating every edit as an original utterance.
What lands on the engagement chat
The thread is for the conversation that explains how the engagement was run, not the per-finding discussion that explains why a specific vulnerability landed where it did. Engagement-wide chat covers the agreements, the schedule, the escalations, and the handovers that apply across many findings. The per-finding conversation surface is a separate, finding-scoped record.
Engagement kickoff and scope clarification
A workspace member opens the engagement, posts the scope confirmation, and asks the client to acknowledge the asset list, the credentials, and the test window. The acknowledgement lands on the engagement chat rather than in a forwarded email, so the next reviewer reads the agreed scope on the record.
Schedule and window coordination
When the team needs to confirm a test window, agree a maintenance pause, or negotiate a retest slot, the back and forth lands on the engagement chat. The agreed window is part of the engagement record alongside the kickoff scope and the closing handover.
Engagement-wide escalation and stop-test signals
A stop-test signal, an emergency escalation, or a scope-pause request applies to the engagement rather than to a single finding. The engagement chat is the place where the request lands, the response is recorded, and the resumption window is agreed.
Status updates and handover at engagement close
A team lead posts the engagement status update, the closing handover, and the retest schedule on the engagement chat. The handover is part of the engagement record rather than a separate report folder that the next reviewer has to find.
Properties that keep the engagement chat defensible
Engagement chat is only useful if it is durable, scoped, attributed, and audit-readable. SecPortal applies the same properties to every message, so the chat surface is consistent across workspaces, engagements, and tenants without per-deployment configuration.
Per-engagement scope
Messages are scoped to a single engagement rather than to a workspace-wide channel. Conversation about scope, schedule, escalation, or handover stays on the engagement it applies to. Cross-engagement chatter does not pollute a record that belongs to a specific client and a specific test window.
Tenant-isolated by row-level security
Supabase row-level security on the messages table only returns rows the reader has access to under the workspace and the engagement. Workspace members read their workspace conversation, client portal users read only the conversation on engagements they have access to, and cross-tenant reads are blocked at the database boundary.
Workspace member and client portal user share one thread
Workspace members send messages from the dashboard engagement view. Client portal users send messages from the portal engagement view. Both write into the same messages table and surface on the same engagement, so the workspace and the portal share one chat rather than two timelines that need reconciling.
Author-controlled edit and delete
A message author can edit or delete their own message. Workspace members with the right RBAC role can manage the engagement chat where a post needs to be removed or corrected. Every change writes an immutable activity log entry so the edit and the deletion stay on the audit trail even when the original content does not.
Visible on the workspace activity log
Each new message fans out as a message.created action on the workspace activity log, with the actor, the engagement title, and a timestamp. The activity feed reads the message in context next to scope updates, document uploads, and finding state changes on the same engagement.
Notification fan-out to the engagement audience
New messages trigger the same notification fan-out the rest of the workspace uses, so engagement leads, owners, and client portal users with access see the message on their in-app notifications inbox without polling the chat tab. 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 engagement records to evidence operating effectiveness rather than narrative claims. Per-engagement messages sit on the same timeline so the rationale behind a scope, a schedule, an escalation, or a handover is recoverable on the same record as the engagement itself.
- Reconstruct the agreed scope, the test window, and the rules of engagement when an auditor asks for evidence on a closed engagement
- Show the timestamp on a stop-test signal, an escalation, or a scope change against the workspace clock that anchors the rest of the engagement record
- Trace the engagement handover to the client portal user by reading the workspace and portal messages together as one thread on the engagement
- Demonstrate segregation of duties between the testers, the engagement lead, and the approving client by reading the actor on each message alongside the role state at the time
- Recover the rationale behind a pause, a retest scheduling decision, or a credential rotation request weeks after the engagement closed, without trusting reconstruction from chat scrollback or email archives
- Evidence the operating effectiveness of an engagement governance policy by reading the kickoff, the mid-engagement updates, and the closing handover on the same record
Handoff surfaces the engagement chat covers
Engagements move between people. Each handoff is a moment where the record on the engagement is the only inheritance the next reader gets. The engagement chat is the surface where the handoff context lives, so the next lead, the client portal user, the retester, or the rotated-in reviewer picks up the engagement with the prior commitments intact.
Workspace to client portal handoff
A workspace member publishes the engagement to the client portal and the client portal user reads the engagement view alongside the chat thread. Scope confirmations, status updates, and closing handovers land on the same record on both sides, so the question and the answer share one timeline rather than living in email.
Engagement lead rotation handoff
An engagement lead rotates off the engagement and a successor takes over. The engagement chat is the single inheritance surface that explains where the engagement stood, what was open, and what the active commitments were. The new lead reads the record once instead of reassembling the history from meeting notes.
Internal security to vendor handoff
For internal security teams running a vendor engagement (a third-party penetration test, an audit fieldwork window, a remediation assistance contract), the engagement chat is the running record of agreement, escalation, and acknowledgement between the internal owner and the external party. The thread carries the engagement context across the vendor boundary.
Retest scheduling and post-engagement handover
When the engagement moves to a retest window or a post-engagement remediation review, the schedule, the readiness signal, and the credential refresh agreement land on the engagement chat. The continuation reads as part of the original engagement rather than as a new conversation with no inherited context.
Who can do what
Message authority follows the workspace team-management RBAC and the messages 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
Send messages on any engagement in the workspace, edit and delete their own messages, and have authority to remove other messages where engagement governance requires it. The activity log records every action so removal stays on the audit trail.
Workspace members
Send messages on engagements they have access to under their RBAC role. Edit and delete their own messages. Authority is enforced by the messages row-level security policy at the database boundary rather than by the UI.
Workspace viewers
Read messages on engagements they have access to but cannot post or modify. The viewer role is the audit and observer profile that reads the engagement record without writing to it.
Client portal users
Read and post messages on engagements the client has access to. Messages from the portal write to the same messages table the workspace uses, so the chat reads as one thread per engagement regardless of which side posted it.
Adjacent surfaces the engagement chat connects to
Per-engagement messages are one part of the workspace conversation surface. Per-finding comments, document attachments, and the workspace activity log each carry a different kind of context, and the engagement record is the integration point so the four surfaces read as one record.
Finding comments
Per-finding comments run alongside per-engagement messages. The comments table covers conversation tied to a specific finding (triage, severity recalibration, fix verification), while the messages table covers conversation that applies across the engagement (scope, schedule, escalation, handover). Both surface on the engagement view so the engagement reads as one record.
Document attachments
When a message refers to evidence (a scope confirmation, an authorization letter, a credential handover, a scanner export, a closing report draft), the artefact lands on the document store attached to the same engagement. The chat and the evidence share one parent record, so the audit chain of custody is recoverable from the engagement rather than from a folder named after a date.
Workspace activity log
Each message.created action lands on the workspace activity log with the actor, the engagement, and the timestamp. The activity feed shows the message alongside scope changes, finding state changes, and document uploads, so the auditor reads the engagement-wide chat in context with the rest of the record.
Where engagement messages fit in your security programme
Engagement messages are the connective tissue between the structured record on an engagement and the human-level coordination that decides how the engagement runs. They plug into engagement management as the chat surface attached to every engagement lifecycle step, into notifications and alerts as the trigger for the per-user inbox fan-out, and into document management as the home for the artefacts the chat refers to (scope confirmations, authorization letters, credential handovers, closing reports).
Per-engagement messages and per-finding comments are sibling surfaces, not duplicates. Engagement messages cover the scope, the schedule, and the handover that apply across many findings. For the per-finding shape that covers triage, severity recalibration, exception rationale, and verification, see finding comments and collaboration. Both surfaces share the same workspace timeline through the activity log, so the engagement view reads as one record even when the conversation moves between engagement-wide context and finding-specific context.
For frameworks that name an evidence or logging control directly, the engagement chat sits on the same timeline as the rest of the workspace record: 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 engagement messages satisfy the platform-level expectation that the rationale behind engagement decisions is recoverable on the same record as the engagement itself.
For the operational workflows the chat thread supports, the conversation attaches directly to the engagement: messages on engagements running penetration testing keep the kickoff, the test-window agreement, and the closing handover on the record; messages on engagements running third-party penetration test report intake keep the vendor coordination on the record; messages on engagements running audit fieldwork evidence request fulfilment keep the auditor-facing exchange on the record; and messages on engagements running security testing programme management keep the cross-engagement coordination on each individual engagement record.
Honest scope: SecPortal does not synchronise the engagement chat to external collaboration platforms (no Slack, Microsoft Teams, Jira, ServiceNow, Linear, or Azure DevOps integration on the message surface). The chat lives on the engagement inside the workspace and the portal. SecPortal does not deliver messages by SMS or external email, and the messages table does not store attachments, reactions, threading, or read receipts; document attachments are handled by document management on the same engagement, and inbox-style read state is handled by notifications and alerts.
Per-engagement messages answer the retrospective question (what was agreed, when, by whom), while the workspace global search palette answers the prospective question (where is the engagement sitting today). Both views read against the same workspace record, so the chat thread and the search index never disagree about what was said or where the engagement lives now.
Keep the conversation on the engagement
Every message carries the actor, the timestamp, and the parent engagement. Workspace and portal share one thread per engagement. The next lead reads the agreement instead of reconstructing it.
No credit card required. Free plan available forever.