Security team on-call rotation
named coverage, structured handover, and an audit-defensible operating record
Most internal security, AppSec, PSIRT, vulnerability management, and security engineering programmes reach a point where the inbound event volume exceeds business hours. Run the rotation as a chartered engagement on the workspace with a named primary, a named secondary, a published escalation authority chain, a structured handover at each shift change, and the activity log capturing the named operator at every event. The discipline that holds the shift on a Tuesday morning is the same discipline the next audit reads against ISO 27001 Annex A 5.24, SOC 2 CC7.3, PCI DSS 12.10, NIST CSF 2.0 RS.MA, NIS2 Article 23, and DORA Article 17.
No credit card required. Free plan available forever.
The on-call rotation is the named-coverage discipline behind the security operating record
Every internal security, AppSec, PSIRT, vulnerability management, and security engineering programme reaches a point where the inbound event volume exceeds business hours. New critical findings land on weekends, KEV additions publish overnight, regulator advisories arrive at 3 a.m. local, customer escalations hit the inbox before the team is awake. The operating answer is a named, rostered, audit-defensible on-call rotation that brings a trained operator to each in-scope event within the documented acknowledgement target, runs a structured handover at each shift change, captures every acknowledgement on the workspace activity log, and tunes the cadence each cycle through a rotation lead retrospective that reads the rotation health metrics from the live record. Done well, the rotation produces the audit-defensible evidence ISO 27001 Annex A 5.24, SOC 2 CC7.3, PCI DSS 12.10, NIST CSF 2.0 RS.MA, NIS2 Article 23, and DORA Article 17 read against. Done badly, the rotation lives in a calendar nobody updates, the handover is a five-minute call the incoming shift forgets, the escalation chain is implicit, and the audit-evidence pack reconstructs from chat history six weeks after the event.
The rotation composes with the rest of the security operating model. The zero-day and emergency vulnerability response workflow names the on-call lead the rotation supplies. The PSIRT product security incident response workflow routes researcher reports to the on-call PSIRT analyst. The SLA-breach escalation workflow rides the escalation chain the rotation policy names. The incident response workflow opens against the rotation when the inbound event escalates to incident scope. The breach notification and regulator readiness workflow reads the in-shift regulator notification clock the rotation captures at acknowledgement.
Six named roles the rotation carries
A rotation that produces an audit-defensible operating record carries six named roles. The role assignment per shift runs against the workspace team-management RBAC so the activity log records the role each actor held at the time of every event.
| Role | Responsibility on the shift | What the role is accountable for |
|---|---|---|
primary_on_call | Holds the active on-call shift for the rotation. Reads inbound vulnerability disclosure intake, scanner-driven critical findings, KEV-listed CVE additions, PSIRT case openings, SLA-breach-imminent alerts, and incident escalations during the shift window. Acknowledges each event against the workspace finding or engagement record at the agreed acknowledgement target. | Accountable for first-touch acknowledgement of every event routed to the rotation, the structured intake record on the workspace at the moment of acknowledgement, and a clean handover to the next shift with no event left in an unacknowledged state. |
secondary_on_call | Backs the primary on-call across the same shift window. Carries the second-touch escalation when the primary cannot acknowledge within the policy target (sickness, sleep, conflicting engagement, paged incident already in progress). Reads the same workspace queues so the second pair of eyes is calibrated to the same record the primary is. | Accountable for the no-single-point-of-failure property of the shift, the second-touch acknowledgement when the primary misses the target, and the cross-check on severity, scope, and decision when the event needs two named operators. |
rotation_lead | Owns the rotation as a programme. Publishes the published roster, sets the shift length and the handover discipline, ratifies the swap and cover policy, holds the post-shift retrospective cadence, and reads the rotation health metrics each cycle (acknowledgement adherence, handover completeness, swap volume, escalation rate, burnout signals). The rotation lead is the vulnerability management lead, the AppSec lead, the PSIRT lead, the security operations lead, or the security engineering lead under the workspace RBAC. | Accountable for the rotation being a published artefact, the shift cadence being humane and sustainable, the handover record being audit-defensible, and the rotation contributing to programme stability rather than to staff churn. |
escalation_authority | Receives the second-tier escalation when the primary and secondary cannot resolve the event within the documented authority window. Holds decision authority over severity overrides, accepted-risk dispositions, exception register entries, public communication, regulator notification triggers, and customer-facing advisories during the on-call window. Usually the CISO, the security director, the head of vulnerability management, the head of AppSec, or a named deputy. | Accountable for the escalated decision carrying named authority, the rationale captured on the workspace record, the framework citation where compliance is in scope, and the post-incident review reading the escalation as either correct or a calibration signal the rotation policy should learn from. |
engineering_remediation_contact | Represents the engineering team that carries remediation work the on-call rotation accepts during the shift. Receives the named-owner routing from the workspace notification when an accept-work disposition lands during the shift. Names the engineer who will drive the fix, accepts a realistic target date, and commits to the proof-of-fix expectation the resolved transition will require. | Accountable for the named-owner field on each accepted finding the on-call rotation hands across, the realistic target date on the in_progress transition, and the proof-of-fix expectation aligning with the workspace state lifecycle policy. |
grc_partner_on_call | Optional on a separate rotation when the programme answers to live regulator notification clocks (DORA Article 19 major-ICT-incident notification, NIS2 Article 23 significant-incident notification, GDPR Article 33 personal-data-breach notification, PCI DSS 12.10 breach response, HIPAA breach notification, SEC cybersecurity disclosure). Reads any in-shift event that may trip a notification clock and brings the framework citation discipline to the disposition before the clock starts. | Accountable for the regulator notification clock being read at the moment of the event rather than after the shift, the notification trigger decision carrying the named approver, and the audit-evidence pack capturing the clock-start timestamp from the workspace activity log rather than from reconstruction. |
Seven event classes the rotation reads against
The rotation acknowledges events from a documented set. Each class lands as a structured intake on the workspace finding or engagement record so the acknowledgement chronology is queryable rather than reconstructed from chat history.
New high-severity finding intake during the shift
Critical or high-severity findings created from scanner intake (external scanning across the sixteen modules, authenticated scanning behind verified domains, code scanning Semgrep SAST and dependency analysis), bulk finding import (Nessus, Burp Suite, CSV from third-party scanners), or manual finding entry during the shift window. The on-call primary reads the cohort, acknowledges the routing on the workspace finding record, and either accepts the routing or escalates.
KEV-listed CVE addition affecting the in-scope estate
A new CISA KEV catalogue addition that the workspace continuous monitoring matches against the in-scope asset estate (verified domains, connected repositories, fingerprinted technology stack, declared dependencies). The on-call primary opens an emergency response engagement, reads the in-shift exposure assessment, and routes to the named asset owner or escalates if the named owner is not available in the shift window.
SLA-breach-imminent alert during the shift
An in_progress finding whose target remediation date falls within the next operating cycle and whose named owner has not produced a fix update inside the shift window. The on-call primary reads the breach-imminent cohort, contacts the named owner, accepts a documented date shift with rationale, or escalates to the named accountable owner so the breach is decided rather than discovered overnight.
PSIRT case opening from an external researcher report
A vulnerability disclosure programme submission, a bug bounty platform handoff, or a customer escalation that opens a PSIRT case during the shift. The on-call primary reads the report, opens the structured PSIRT case on the workspace, acknowledges the reporter through the case record, and routes to the named PSIRT analyst for triage.
Supplier advisory cascade affecting product code
A security advisory from an upstream supplier (open source maintainer, vendor library, cloud provider, OEM) that requires the company to issue its own advisory to downstream consumers. The on-call primary reads the upstream advisory reference, opens the cascade case on the workspace, and routes the in-shift exposure assessment to the named product security owner.
Continuous monitoring detection of regression or recurrence
A continuous monitoring scan that re-detects a previously verified-closed finding (regression), a finding pattern across a previously suppressed false-positive cohort (suppression failure), or a fresh open finding against an asset that completed an attestation cycle (attestation regression). The on-call primary reads the regression source and routes restoration to the original-severity workflow.
Zero-day or emergency vulnerability response trigger
A trigger event covered by the emergency vulnerability response workflow: a published exploit kit, a confirmed in-the-wild exploitation report, a regulator advisory naming the company sector, a customer-facing dependency advisory. The on-call primary reads the trigger event, opens the emergency response engagement, and routes the named on-call lead for exposure assessment.
Seven failure modes that quietly break the rotation
Most rotation failures look like sensible defaults: keep the roster in a calendar, hand over verbally, share the firehose between primary and secondary, escalate to whoever answers. The cost arrives weeks later as an audit finding, a missed regulator clock, a burned-out operator, and a programme that cannot answer the question "who acknowledged this event at this timestamp".
The rotation lives in a calendar, not on the workspace
The shift roster sits in a shared calendar or a wiki page; the workspace has no record of who held the shift when the critical finding landed. The next audit asks for the named operator who acknowledged the SLA-breach-imminent alert at the timestamp on the activity log; the answer is "let me find the calendar from that week". The fix is the rotation roster being a document on the engagement record with named operators per shift window and the workspace activity log capturing the named acknowledger at the moment of every event.
Handover is verbal and the next shift starts blind
The outgoing shift hands over in a five-minute call; the incoming shift starts the cycle without context on the open events, the in-flight escalations, the breach-imminent cohort still in motion, or the renewals expiring in the next window. The fix is the handover being a structured record on the engagement: open-event count and named owners, in-flight escalations with named authority, breach-imminent cohort with target dates, expiring exceptions with renewal candidates, and the running notes the activity log carries from the prior shift.
Primary and secondary share the same event firehose without role separation
Both the primary and the secondary read every notification. Both pick up the easy events first, both ignore the harder ones, and the rotation collapses into a queue with two operators instead of a rotation with a primary and a backup. The fix is the role separation living in the workspace notification routing and the team management RBAC: the primary acknowledges, the secondary watches for missed-target events, and the activity log records who held each role at each event.
Escalation authority is implicit and the second tier never receives the page
The shift policy says "escalate critical events" but does not name the operator who receives the escalation, the channel the escalation rides on, or the acknowledgement target. When the primary cannot resolve and the secondary is unreachable, the event ages in the queue because the third tier was never named. The fix is the escalation authority being a named role on the rotation policy, the activity log carrying the page-out event, and the workspace finding record stamping the named authority on the disposition.
Cover and swap are negotiated in chat and never recorded on the roster
An operator covers for another mid-shift; the swap happens in a direct message; the published roster still shows the original operator. Six weeks later the audit asks for the named acknowledger at the timestamp on the activity log; the activity log shows operator A but the chat history shows operator B was on call. The fix is the cover and swap policy writing the change onto the document-management copy of the roster with the named substitute, the named approver of the swap, and the activity log capturing the substitution against the affected shift window.
The rotation has no cadence for retrospective and burnout signals are ignored
The rotation runs week after week without a structured retrospective. Acknowledgement adherence drifts, swap volume climbs, the same two operators carry every weekend, and the rotation produces resignations rather than security outcomes. The fix is the rotation lead running a documented retrospective each cycle that reads the rotation health metrics from the workspace activity log (acknowledgement adherence, handover completeness, swap volume, escalation rate per shift, alert volume per shift) and tuning the cadence against the signal before it produces burnout.
Regulator notification clocks start ticking before the on-call rotation reads them
A DORA, NIS2, GDPR, PCI DSS, HIPAA, or SEC notification clock starts the moment the on-call rotation acknowledges a confirmed event with notification scope. The shift policy treats notification as "we will handle it Monday"; the regulator clock does not pause for the weekend; the programme misses the obligation window. The fix is the GRC partner on call (or a documented escalation to the GRC lead) reading any in-shift event that may trip a notification clock at the moment of acknowledgement, with the clock-start timestamp captured on the workspace activity log so the audit-evidence pack reconstructs the timing from the live record.
Six fields every shift handover records
A structured handover writes six fields onto the engagement record at shift close. The handover is a workspace document, not a five-minute call the incoming shift forgets ten minutes in.
Outgoing shift summary
The outgoing shift writes a structured summary on the engagement record at shift close: event count handled, severity mix, named owners contacted, accept-work dispositions routed, escalations triggered, exceptions accepted with named expiry, breach-imminent cohort status, and a free-text note for anything the next shift needs to read first. The summary is a document the next shift opens to before the workspace queue.
Open events with named follow-up
Every event the outgoing shift acknowledged but did not close lands on the handover record with the named follow-up operator (incoming primary, named asset owner, named PSIRT analyst, named engineering remediation contact). The next shift opens the cohort as the first cohort it reads against, not as a surprise that surfaces later in the shift.
In-flight escalations and authority decisions pending
Any escalation the outgoing shift triggered carries forward with the named escalation authority, the pending decision class, the target acknowledgement window for the authority, and the workspace finding or engagement reference. The incoming shift reads the escalation cohort as a watch list and is not surprised by an authority page-out in the middle of the new shift.
SLA-breach-imminent cohort and target dates
The breach-imminent cohort that the outgoing shift identified or carried forward lands on the handover with the named owners, the target dates, the latest update each owner produced, and the rationale on any documented date shift. The incoming shift opens the cohort as a working list and either confirms the dates hold or escalates against the same authority chain the outgoing shift would have.
Expiring exceptions and renewal candidates
Active overrides whose review or expiry date falls in the incoming shift window land on the handover with the named approver, the renewal candidate evidence, and the framework citation grid. The incoming shift either holds the renewal in the disposition meeting agenda or escalates to the named approver if the policy requires.
Rotation health and burnout signals
The outgoing shift records the qualitative signals the activity log alone cannot capture: was the shift volume sustainable, did the rotation lose sleep on a non-actionable page, was a swap or cover negotiated mid-shift, did the rotation feel like an operating discipline or a queue. The signal feeds the rotation lead retrospective so the cadence tunes against burnout before it produces resignation.
Five operating cadences for the rotation
The right cadence depends on programme volume, regulator scope, and team distribution. Most enterprise programmes run a stacked cadence: a tighter operational rotation for active shifts and a separate elevated rotation for audit and release windows.
- Weekly shift rotation for high-volume programmes (mature AppSec, enterprise vulnerability management, PSIRT for shipping product). The primary and secondary rotate weekly so each operator carries roughly one week per month. The shift week is the unit the retrospective reads.
- Biweekly shift rotation for mid-volume programmes. Pairs with a monthly retrospective and works for teams where the alert volume is bounded enough that one operator can absorb a fortnight without burnout.
- Daily handover with weekly shift rotation for global teams. The shift carries across time zones with a daily handover document so the team-management roster reads as a follow-the-sun rotation with named operators across a primary, a secondary, and an escalation authority per regional shift.
- Event-driven on-call activation for low-volume programmes. The rotation is dormant most of the time and activates against named trigger events (KEV addition, PSIRT case opening, SLA-breach-imminent alert, zero-day notification, regulator advisory). The handover is the trigger event itself; the activation policy is the document on the engagement record.
- Pre-audit and pre-release elevated rotation. The shift rotation tightens in the window before an ISO 27001 surveillance, a SOC 2 review, a PCI DSS assessment, a regulatory examination, or a major product release. The primary and secondary read the audit-evidence cohort each shift and stage the cohort against the framework citation grid the auditor will read.
How the rotation runs in SecPortal
The rotation runs on the workspace surfaces the security programme already uses. Team management RBAC binds the named operator per shift. Notifications and alerts route inbound events. The activity log captures the operator chronology. Engagement management opens the rotation as a chartered record. Document management holds the policy, the roster, and the handover artefacts. No bespoke integration is required; the platform capabilities below carry the rotation end to end on the workspace side, with the paging-delivery layer explicitly out of scope.
Team management RBAC as the rotation roster spine
Team management with role-based access control governs which workspace members can chair the shift, who can stamp severity overrides, and who can approve accepted-risk dispositions during the shift. The role assignment per shift is the structured record the activity log captures against every event the rotation acknowledges.
Notifications and alerts routing to the named on-call operator
Notifications and alerts push the inbound event to the workspace member assigned the on-call role for the shift, with the bell-icon real-time alert in the dashboard and the engagement context the operator needs to acknowledge against the finding or engagement record.
Activity log for acknowledgement chronology and named operator capture
Activity log with CSV export captures the named operator and the timestamp at the moment of every acknowledgement, every routing decision, every escalation page-out, and every disposition the shift records. The chronology is queryable per shift window so the audit reads the operator history from the live record.
Engagement management for the rotation as a workspace record
Engagement management opens the rotation as a chartered engagement on the workspace so the roster, the handover records, the retrospective notes, and the rotation health metrics live against a single engagement rather than scattered across documents and chat channels.
Document management for the rotation policy and handover artefacts
Document management holds the rotation policy, the published roster, the swap and cover policy, the named escalation authority chain, the handover record per shift, and the retrospective notes per cycle as versioned attachments on the engagement record the audit reads against.
Multi-factor authentication on the on-call workspace boundary
Multi-factor authentication with TOTP keeps the on-call operator identity bound to the named role on the rotation roster. The workspace activity log captures the authenticated session that acknowledged each event so the named-operator attribution is not interchangeable with a shared login.
Findings management for the acknowledged finding record
Findings management with CVSS 3.1 carries the on-call acknowledgement on the finding record itself: status change, assignee, severity (with override capture), target date, and notes. The shift record is the workspace record, not a parallel ticket.
AI reports for the post-shift summary draft
AI report generation drafts the post-shift summary and the rotation retrospective pack from the live workspace record (acknowledgement volume, severity mix, escalation rate, breach-imminent cohort handled, exceptions accepted) rather than from a separately written shift note.
Compliance tracking for regulator notification clock alignment
Compliance tracking reads the in-shift dispositions against ISO 27001 Annex A 5.24, SOC 2 CC7.3, PCI DSS 12.10, NIST SP 800-53 IR-2 and IR-4, NIST CSF 2.0 RS.MA and RS.CO, NIS2 Article 23, and DORA Article 17 and 19 so the framework citation grid is captured during the shift rather than reconstructed during fieldwork.
What SecPortal does not do for the rotation
SecPortal is the workspace-side rotation record, not the paging delivery layer and not the shift scheduling engine. The honest scope below names the boundaries the rotation policy should write down so the team chooses the right partner discipline for each layer.
- SecPortal does not include a built-in shift scheduling engine. The rotation roster is a document on the engagement record and a workspace member assignment under team-management RBAC; SecPortal does not generate the schedule the way PagerDuty, Opsgenie, Splunk On-Call, Squadcast, FireHydrant, incident.io, or Rootly do.
- SecPortal does not page operators through SMS, voice call, or push notification. Notifications and alerts deliver to the in-app bell and the workspace email channel; the paging layer (PagerDuty, Opsgenie, Twilio, mobile push from a dedicated paging app) remains a separately operated discipline the rotation policy documents the boundary against.
- SecPortal does not ship packaged native integrations into PagerDuty, Opsgenie, Splunk On-Call, FireHydrant, incident.io, Rootly, Squadcast, Slack, Microsoft Teams, ServiceNow, Jira, Zendesk, Freshdesk, SIEM platforms, SOAR platforms, MDR platforms, IdP federation, SSO, SCIM, or SAML provisioning. The rotation operates on the workspace record itself; downstream paging and ticketing remain customer-managed.
- SecPortal does not enforce shift coverage. The rotation lead reads the activity log for acknowledgement adherence and gaps; SecPortal does not auto-page a backup operator when the primary misses a target the way a dedicated paging service does.
- SecPortal does not run the regulator notification process itself. The compliance-tracking framework citation grid records the in-shift acknowledgement clocks against the named framework; the regulator notification submission, the customer breach notification, and the regulator portal filing remain operated by the GRC team through the channels the regulator names.
- SecPortal does not infer operator availability, on-call fatigue, or burnout. The rotation lead reads the workspace activity log and the qualitative signals captured on the handover record; SecPortal does not predict burnout or recommend roster adjustments the way some specialist incident-response platforms do.
- SecPortal does not run identity governance. Team-management RBAC binds the named operator to the workspace; SecPortal does not federate to an external IdP for on-call group membership the way IGA platforms or identity-aware paging services do.
- SecPortal does not replace incident response retainers, MDR services, MSSP coverage, or external SOC contracts. The rotation discipline lives on the workspace; the external coverage relationships remain operated through the contracts the security operations leader and the CISO negotiate separately.
Audit frameworks that read against the rotation record
Enterprise audit and certification cycles ask for evidence that the security programme runs a named-coverage discipline against in-scope events with an audit-defensible chronology and a documented escalation chain. The rotation policy and the workspace activity log are the evidence those audits read against.
ISO 27001:2022
Annex A 5.24 (information security incident management planning and preparation) reads against the on-call rotation as the structured evidence that the programme operates a named, rostered, and audit-defensible coverage discipline rather than an ad hoc availability assumption. Annex A 5.25 (assessment and decision on information security events) reads against the in-shift acknowledgement timestamps and the named operator at each event. Annex A 5.27 (learning from information security incidents) reads against the rotation retrospective cadence and the health metrics the rotation lead captures each cycle.
SOC 2 Trust Services Criteria
CC7.3 (system operations and security event response) reads against the on-call rotation as the named-operator response discipline the workspace records against every event. CC4.1 (monitoring activities) reads against the rotation health metrics the rotation lead captures each cycle. CC2.2 (internal communication) reads against the handover record and the escalation chain on the rotation policy.
PCI DSS v4.0
Requirement 12.10 (incident response and breach response) reads against the rotation as the named coverage discipline that brings a trained operator to each in-scope event within the documented acknowledgement target. Requirement 12.5 (information security responsibilities) reads against the named rotation roles and the team-management RBAC backing the rotation.
NIST SP 800-53 Rev. 5
IR-2 (incident response training) reads against the rotation training discipline and the operator qualifications the rotation lead validates each cycle. IR-4 (incident handling) reads against the in-shift acknowledgement, routing, and escalation discipline the workspace records. IR-7 (incident response assistance) reads against the escalation authority chain on the rotation policy. CP-2 (contingency plan) reads against the cover and swap policy the document-management copy of the roster captures.
NIST CSF 2.0
The Respond (RS) function reads against the rotation as the operating discipline that runs the response. RS.MA (incident management) reads against the named-operator acknowledgement at each event. RS.CO (incident response communications) reads against the handover record and the escalation chain. The Govern (GV) function reads against the rotation policy itself as the audit-defensible artefact that names the operating discipline.
CIS Controls v8.1
Control 17 (incident response management) reads against the on-call rotation as the named-coverage discipline that satisfies Control 17.1 (designated personnel to manage incident handling). Safeguard 17.2 (establish and maintain contact information) reads against the rotation roster as the workspace record of named operators and named contact paths.
NIS2 and DORA
NIS2 Article 21 (cybersecurity risk-management measures) reads the rotation as a named risk-management measure. NIS2 Article 23 (significant-incident notification) reads the rotation as the discipline that recognises notification-scope events at the moment of acknowledgement so the regulator clock starts on the documented timestamp rather than on Monday morning. DORA Article 17 (ICT-related incident management process) and Article 19 (major-ICT-incident notification) read against the GRC-partner-on-call discipline and the in-shift framework citation grid.
Where the rotation fits in the wider operating model
The rotation reads from adjacent workflows and writes back to them. The references below trace how the rotation discipline carries into the rest of the security operating model so the on-call shift is the operating record the audit reads from, not a parallel log the team has to maintain.
Zero-day and emergency response
The zero-day and emergency vulnerability response workflow opens the in-shift emergency response engagement against the named on-call lead the rotation supplies.
PSIRT product security IR
The PSIRT product security incident response workflow routes researcher reports, bug bounty handoff, and customer escalations to the on-call PSIRT analyst the rotation supplies.
SLA-breach escalation
The SLA-breach escalation workflow rides the escalation authority chain the rotation policy names so deputy approvers cover leave and rotation without breaking the chain.
Incident response
The incident response workflow opens against the rotation when the inbound event escalates to incident scope so the named responder and the auto-escalation read against the same workspace roster.
Breach notification readiness
The breach notification and regulator readiness workflow reads the in-shift regulator clock the GRC partner on call captures at the moment of acknowledgement so the notification window does not start unobserved.
Finding disposition meeting
The finding disposition meeting workflow picks up the batched cohort the rotation routes during the shift and writes the documented decision record against the same workspace activity log.
SLA management
The SLA management workflow defines the per-severity target dates the rotation reads against when the breach-imminent cohort lands during the shift.
Post-incident lessons learned
The post-incident lessons learned workflow reads the rotation retrospective each cycle so the rotation health metrics inform the programme-side action ledger.
Audit fieldwork evidence
The audit fieldwork evidence workflow pulls the rotation activity log CSV export as the chronology evidence the auditor reads against the framework citation grid.
Buyer audiences for the on-call rotation workflow
The rotation serves the operators and leaders responsible for the named-coverage discipline the programme records against every in-scope event. Each audience reads the rotation with a different lens.
Internal security teams and security operations leaders
Carry the rotation across the active security team. Read the workspace as the system of record for who is on call when, the acknowledgement chronology per event, the escalation chain, and the retrospective metrics that tune the cadence. The published roster is an audit-defensible artefact the audit and assurance team reads against ISO 27001 Annex A 5.24 and SOC 2 CC7.3.
Internal security teamsAppSec teams and product security teams
Run the PSIRT-side rotation that responds to vulnerability disclosure intake, bug bounty handoff, customer escalation, and supplier advisory cascade against the company product. The rotation reads the workspace findings record at the moment of each event and routes the named PSIRT analyst rather than a shared inbox the team checks asynchronously.
AppSec teamsVulnerability management teams
Run the breach-imminent and KEV-addition rotation that catches in-shift critical exposures (new KEV listings, EPSS spikes, zero-day notifications, regulator advisories) and routes the named asset owner before the breach window closes. The rotation reads the workspace continuous monitoring queue and acts against the live finding record.
Vulnerability management teamsSecurity engineering teams
Carry the platform-side rotation that responds to in-shift platform-security events: pipeline-as-code scanner alerts, dependency advisory cascades, secret-scanning critical alerts, repository-connection authentication failures, scanner authentication failure modes. The rotation reads the workspace as the operating record for platform-tier events.
Security engineering teamsGRC and compliance teams
Pair with the security rotation as the GRC-partner-on-call discipline when the programme answers to live regulator notification clocks (DORA, NIS2, GDPR, PCI DSS, HIPAA, SEC). Read the in-shift event class for notification scope at the moment of acknowledgement so the regulator clock starts on a documented timestamp rather than on a Monday-morning reconstruction.
GRC and compliance teamsCISOs and security directors
Read the rotation as a programme-health signal. The rotation policy, the published roster, the handover discipline, the escalation authority chain, the retrospective cadence, and the activity log together produce the audit-defensible evidence the board risk committee, the audit committee, and the assurance partner read against the named risk-management measures the framework set the programme answers to expects.
CISOs and security directorsFrequently asked questions about the security team on-call rotation
What is a security team on-call rotation?
A security team on-call rotation is the rostered named-coverage discipline that brings a trained security operator to each in-scope event (new critical finding intake, KEV catalogue addition, SLA-breach-imminent alert, PSIRT case opening, zero-day or regulator advisory) within a documented acknowledgement target. The rotation publishes a roster with named primary, named secondary, and named escalation authority per shift window, runs a structured handover at each shift change, captures every event acknowledgement on the workspace activity log, and reads rotation health metrics each cycle so the cadence stays humane and sustainable while the audit-evidence pack stays current. The rotation is the operating answer to the question "who is responsible the moment this event lands" rather than the wishful answer that "the security team will pick it up".
How is the on-call rotation different from a paging service like PagerDuty?
A paging service (PagerDuty, Opsgenie, Splunk On-Call, Squadcast, FireHydrant, incident.io, Rootly) is the delivery layer that pages the named operator: SMS, voice call, push notification, shift schedule engine. SecPortal does not replace that layer. The SecPortal on-call rotation is the workspace-side discipline: the named operator per shift, the structured event acknowledgement on the workspace finding or engagement record, the handover content, the escalation authority chain, the activity log chronology, the framework citation grid for audit. Programmes that run a dedicated paging service for delivery still need the workspace-side discipline so the audit reads the operator and the disposition against the structured record rather than against the paging-service-only log.
Who staffs a security team on-call rotation?
A workable rotation carries a named primary operator (the active shift-holder), a named secondary operator (the backup for the same shift window), a named rotation lead (the programme owner who publishes the roster and runs the retrospective), and a named escalation authority (the CISO, security director, head of vulnerability management, head of AppSec, head of security operations, or a named deputy). Programmes with regulator notification clocks pair a GRC partner on call for the in-shift framework citation discipline. Programmes that carry engineering remediation through the shift pair an engineering remediation contact for accept-work dispositions during the shift. Team-management RBAC binds each operator to the named role so the activity log records the role each actor held at the time of each event.
What shift cadence works for an internal security team on-call rotation?
Weekly shifts work for high-volume programmes (mature AppSec, enterprise vulnerability management, PSIRT for shipping product) where the primary and the secondary rotate weekly so each operator carries roughly one week per month. Biweekly works for mid-volume programmes pairing with a monthly retrospective. Daily handover with weekly shifts works for global teams running follow-the-sun coverage across regional shifts. Event-driven activation works for low-volume programmes where the rotation is dormant most of the time and activates against named trigger events. Pre-audit and pre-release windows tighten the rotation against the audit-evidence cohort the auditor will read. The rotation lead tunes the cadence each cycle against the rotation health metrics (acknowledgement adherence, swap volume, escalation rate, alert volume per shift) to keep the cadence sustainable.
What does the shift handover record include?
A structured handover writes six fields onto the engagement record at shift close: outgoing shift summary (event count, severity mix, named owners contacted, accept-work dispositions routed, escalations triggered, exceptions accepted with named expiry, breach-imminent cohort status), open events with named follow-up, in-flight escalations with named authority and pending decision class, SLA-breach-imminent cohort with named owners and target dates, expiring exceptions and renewal candidates with named approver, and rotation health and burnout signals as qualitative notes. The handover is a document on the workspace engagement record, not a five-minute call the incoming shift forgets ten minutes in.
How does the rotation handle escalation when the primary cannot resolve an event?
The rotation policy names the escalation authority chain in advance. The primary acknowledges and works the event; the secondary cross-checks and absorbs missed-target events; the escalation authority (CISO, security director, head of vulnerability management, head of AppSec, head of security operations, or named deputy) receives the second-tier page-out when the primary and secondary cannot resolve within the documented authority window. Notifications and alerts route the page-out to the named authority on the workspace; the activity log stamps the page-out event with the named primary, the named secondary, the named authority, and the timestamp; the workspace finding or engagement record carries the escalated disposition with the named authority on the override.
How does the rotation handle swap, cover, and out-of-office?
The rotation policy publishes the swap and cover policy as a document on the engagement record. Any swap (an operator covering for another mid-rotation) writes the change onto the document-management copy of the roster with the named substitute, the named approver of the swap, the original operator, the affected shift window, and the rationale. The activity log captures the substitution at the workspace level so the audit reads the named acknowledger from the live record rather than from chat history. Out-of-office windows the rotation lead reads in advance route to the cover policy before the shift opens, never mid-shift in a panicked direct message.
Does the rotation work for AppSec, PSIRT, vulnerability management, and security operations all at once?
A workable rotation matches the inbound event class to the operator class. A unified rotation works for small programmes where one operator pool reads every event class. Most enterprise programmes run separate but coordinated rotations: an AppSec or product security rotation reads PSIRT case openings and bug bounty handoff; a vulnerability management rotation reads KEV additions, SLA-breach-imminent alerts, and zero-day notifications; a security operations rotation reads incident response triggers; a security engineering rotation reads platform-tier events. Each rotation runs on the same workspace engagement-record discipline with named roles, handover records, escalation chains, and activity log capture; the rotation lead per programme tunes the cadence against the programme volume.
How does the rotation produce audit evidence?
Every event acknowledgement writes a row to the workspace activity log with the named operator, the named role, the timestamp, the affected finding or engagement, the routing decision, and the disposition. Every escalation page-out writes a row with the named authority. Every override during the shift writes the eight-field override chain on the finding overrides feature with the named approver and the rationale. Every shift handover writes a document on the engagement record. The CSV export from the activity log produces the audit-evidence pack auditors and assurance teams cite by line for ISO 27001 Annex A 5.24 and 5.25 and 5.27, SOC 2 CC7.3 and CC4.1 and CC2.2, PCI DSS 12.10 and 12.5, NIST SP 800-53 IR-2 and IR-4 and IR-7 and CP-2, NIST CSF 2.0 RS.MA and RS.CO and GV, CIS Controls v8.1 control 17, NIS2 Article 21 and Article 23, and DORA Article 17 and Article 19.
How does the rotation align with regulator notification clocks?
Programmes that answer to live regulator notification clocks (DORA Article 19 major-ICT-incident notification, NIS2 Article 23 significant-incident notification, GDPR Article 33 personal-data-breach notification, PCI DSS 12.10 breach response, HIPAA breach notification, SEC cybersecurity disclosure) pair a GRC partner on call with the security rotation. The GRC partner reads any in-shift event for notification-scope criteria at the moment of acknowledgement so the regulator clock starts on the workspace-stamped timestamp rather than on the Monday-morning reconstruction. Compliance tracking carries the framework citation grid and the named approver on the notification decision; the regulator portal submission, the customer breach notification, and the regulator engagement remain operated through the GRC team channels.
How does the rotation pair with the disposition meeting and the SLA workflow?
The on-call rotation handles the moments when an event needs an operator now. The disposition meeting handles the batched cohort that needs a decision against documented options. The SLA management workflow defines the per-severity target dates the rotation reads against, and the SLA-breach escalation workflow runs the breach-imminent cohort the rotation either confirms or escalates against the same authority chain. The rotation, the meeting, and the SLA discipline all read the same workspace findings record, the same activity log, and the same team-management RBAC; the audit reads one coherent operating record rather than three separate logs.
How does SecPortal hold the rotation without a built-in scheduling engine?
SecPortal opens the rotation as a chartered engagement on the workspace with the rotation policy, the published roster, the swap and cover policy, the escalation chain, and the retrospective cadence as document-management artefacts on the engagement record. Team-management RBAC binds the named operator per shift to the workspace role the activity log captures against every event. Notifications and alerts route inbound events to the named operator. Findings management captures the acknowledged finding record. Activity log captures the operator chronology. AI report generation drafts the post-shift summary and the rotation retrospective pack. Compliance tracking carries the framework citation grid. The scheduling layer (PagerDuty, Opsgenie, calendar-based rosters, follow-the-sun engines) remains operated separately; SecPortal is the workspace-side discipline that produces the audit-defensible record the audit cycle reads against.
How often should the rotation lead run a retrospective?
A workable cadence runs a structured retrospective each cycle (weekly for weekly shift rotations, biweekly for biweekly, monthly steering for the rotation programme as a whole, quarterly programme review aligning with leadership reporting). The retrospective reads four signals from the workspace activity log: acknowledgement adherence per shift, swap and cover volume per cycle, escalation rate per shift, alert volume per shift; and three signals from the handover record: handover completeness, qualitative burnout signal, retrospective decision adherence from the prior cycle. The retrospective writes the decisions back to the rotation policy so the cadence tunes against the signal before burnout produces resignation.
How it works in SecPortal
A streamlined workflow from start to finish.
Publish the rotation policy as a workspace record
Open the rotation as a chartered engagement on the workspace with the named operator pool, the shift length and cadence, the swap and cover policy, the documented escalation authority chain, the handover discipline expectations, and the retrospective cadence. Document management holds the policy as a versioned artefact the audit cycle reads against rather than as a wiki page or a calendar invite.
Assign the six named roles per shift under team-management RBAC
Assign the primary on-call, the secondary on-call, the rotation lead, the escalation authority, the engineering remediation contact, and (where regulator notification clocks apply) the GRC partner on call per shift window under workspace RBAC. The role assignment per shift is the structured record the activity log captures against every event the rotation acknowledges so the audit reads the named operator from the live record.
Route inbound events through notifications and alerts to the named on-call operator
Notifications and alerts push every inbound event class to the workspace member assigned the on-call role for the shift: new high-severity finding intake, KEV additions, SLA-breach-imminent alerts, PSIRT case openings, supplier advisory cascades, continuous monitoring regression detection, and zero-day or emergency vulnerability response triggers. The in-app bell delivers the engagement context the operator needs to acknowledge against the finding or engagement record.
Acknowledge each event on the workspace finding or engagement record
The on-call primary acknowledges the event by updating the finding or engagement record at the documented acknowledgement target: status change, severity confirmation, named assignee, target date if remediation work is accepted, override capture if severity is downgraded with rationale, and a note for the chronology. The acknowledgement writes a row to the activity log with the named operator, the named role, and the timestamp. The shift record is the workspace record, not a parallel ticket.
Escalate against the documented authority chain when needed
When the event needs second-tier or escalation-authority decision (severity override, accepted-risk disposition, exception register entry, public communication, regulator notification trigger, customer-facing advisory), notifications route the page-out to the named authority on the workspace. The activity log stamps the page-out event with the named primary, the named secondary, the named authority, and the timestamp. The escalated disposition lands on the finding or engagement record with the named authority on the override.
Capture any in-shift regulator notification clock against the framework citation grid
The GRC partner on call (or the documented escalation to the GRC lead) reads any in-shift event for notification-scope criteria at the moment of acknowledgement: DORA Article 19 major-ICT-incident notification, NIS2 Article 23 significant-incident notification, GDPR Article 33 personal-data-breach notification, PCI DSS 12.10 breach response, HIPAA breach notification, SEC cybersecurity disclosure. Compliance tracking captures the framework citation and the clock-start timestamp on the activity log so the audit-evidence pack reads the clock from the live record.
Hand over to the next shift with a structured handover record
At shift close, the outgoing shift writes the six-field handover record on the engagement: outgoing shift summary, open events with named follow-up, in-flight escalations and authority decisions pending, SLA-breach-imminent cohort and target dates, expiring exceptions and renewal candidates, rotation health and burnout signals. The incoming shift opens the handover document as the first read of the shift rather than encountering open events as surprises.
Run the rotation lead retrospective each cycle against rotation health metrics
The rotation lead runs the documented retrospective at the cadence cycle close (weekly for weekly shifts, biweekly for biweekly, monthly steering, quarterly programme review). AI report generation drafts the retrospective pack from the live workspace record: acknowledgement adherence per shift, swap and cover volume, escalation rate per shift, alert volume per shift, handover completeness, qualitative burnout signals. The retrospective writes the decisions back to the rotation policy so the cadence tunes against the signal before burnout produces resignation.
Features that power this workflow
Collaborate across your entire team
Notifications and alerts for the people who carry the work
Every action recorded across the workspace
Orchestrate every security engagement from start to finish
Document management for every security engagement
Multi-factor authentication on every workspace
Vulnerability management software that tracks every finding
AI-powered reports in seconds, not days
Compliance tracking without a full GRC platform
Finding overrides that survive every scan cycle
Finding comments and collaboration on the same record as the work
Global search across every engagement, finding, and client
Run the rotation on the workspace, not on a calendar
Named primary and secondary, escalation authority chain, structured handover, activity log chronology, rotation health retrospective, and the audit citation grid on one engagement record. Free plan available.
No credit card required. Free plan available forever.