For security program architects
who design the operating model the rest of the security org runs on

A security programme platform built around the operating model the architect designs

Security program architects own the operating model behind the security programme. The work spans the capability map across vulnerability management, AppSec, product security, cloud security, GRC, and security operations; the record model behind every finding, exception, retest, and audit-evidence artefact; the scanner-to-finding pipeline architecture across SAST, SCA, authenticated DAST, external scanning, and bulk import; the control catalogue and the cross-framework crosswalk; the evidence collection architecture for audit fieldwork; the team and role architecture; the tool rationalisation and consolidation plan; and the multi-year capability roadmap the CISO, the security program manager, and the engineering counterparts read against. Most architectures carry this work in a slide deck, a Confluence space, a tool inventory spreadsheet, a control catalogue document, and a governance forum calendar, and pay the cost in operating-model drift between cycles and in operations teams that build against a different model than the one the architecture council intended.

SecPortal gives security program architects one workspace for engagement records per architectural workstream, a typed findings record with CVSS 3.1 calibration across every source pipeline, code scanning against connected GitHub, GitLab, and Bitbucket repositories under OAuth, authenticated DAST with encrypted credential storage, external scanning across the verified perimeter, scheduled scans, scan comparison and diff, retesting workflows paired to the original finding, structured exception records with the eight-field decision chain, compliance tracking across 21 frameworks, AI-assisted programme reporting, document management for blueprints and decision records and roadmaps, role-based access control across owner, admin, member, viewer, and billing roles, multi-factor authentication, and an append-only activity log on top. The operating model the architect designs against and the operating model the workspace ships are the same record rather than two artefacts the operations team rebuilds from each other on contact.

Capabilities security program architects design against day to day

How security program architects design and ship the operating model inside SecPortal

A security operating model that survives contact with operations holds up across a small set of disciplines. The capability map, the record model, the scanner-to-finding pipeline architecture, the control catalogue, the evidence collection architecture, the team and role architecture, and the roadmap inherit each one rather than fragment across parallel decks and shared drives.

From operating model design to architecture council readout, on one engagement record

The architectural design loop is open the workstream, define the typed record, wire the scanner-to-finding pipeline, design the control catalogue once, define the exception governance and retesting architecture, define the team and role architecture, define the evidence collection architecture, generate the architecture council and steering view, and read the recurring cadence. SecPortal runs a single workflow the architect, the security program manager, the vulnerability management lead, the AppSec lead, the GRC owner, the cloud security lead, the security engineering lead, the security operations leader, and the CISO can all work against without re-keying state into another tool.

1. 1Open an engagement per architectural workstream: programme operating model design, capability map review, scanner-to-finding pipeline architecture, control catalogue rollout, evidence collection architecture, team and role architecture, tooling rationalisation, capability roadmap review. Attach the blueprint, the capability map, the data model diagram, the scanner inventory, the control catalogue, and the roadmap as documents on the engagement record. The architectural intent and the operational record live on the same workspace from the first council meeting.
2. 2Define the typed finding record the rest of the programme captures against. CVSS 3.1 vector, severity band, status state, named owner, source pipeline tag, asset reference, evidence attachment, and the engagement record reference are the columns every team writes against. SAST, SCA, authenticated DAST, external scanning, bulk-imported third-party scanner output, manually logged pentest findings, and bug bounty intake all populate the same record shape rather than four parallel models.
3. 3Wire the scanner-to-finding pipeline architecture as a workspace primitive. Connect GitHub, GitLab, or Bitbucket through OAuth for code scanning. Provision authenticated DAST credentials through encrypted credential storage. Verify domains through DNS TXT, file upload, or meta tag for external scanning. Configure scheduled scans on the documented cadence. Configure bulk finding import for the rest of the scanner estate.
4. 4Design the control catalogue once and let cross-framework compliance tracking ride it. Map engagement records against ISO 27001 Annex A, SOC 2 Trust Services Criteria, PCI DSS requirements, NIST SP 800-53 control families, NIST CSF 2.0 functions, NIST SSDF, OWASP ASVS, OWASP SAMM, CIS Controls, Cyber Essentials, and the other supported frameworks on the same record, so one rollout satisfies multiple audit packs in parallel.
5. 5Define the exception governance architecture against the eight-field decision chain: linked finding, severity, compensating controls, residual likelihood, residual impact, business rationale, named approver, and expiry with review cadence. Define the retesting workflow as the closure leg of the lifecycle, with closure evidence paired to the original finding and the closure event landing on the activity log.
6. 6Define the team and role architecture against role-based access control. Map architecture council participants, capability owners, audit observers, vulnerability management operators, AppSec leads, product security leads, GRC owners, cloud security leads, security engineering leads, security operations leaders, and engineering counterparts to the owner, admin, member, viewer, and billing roles. Enforce multi-factor authentication on every account when the workspace requires it.
7. 7Define the evidence collection architecture as the append-only activity log plus the structured record set. Plan retention covers 30 days on Starter, 90 days on Pro, and 365 days on Team. CSV export keeps the trail reproducible across plans. The audit fieldwork pull reads against the activity log, the retest record, the exception decision chain, the scan diff change-event record, the override decision record, and the document version history.
8. 8Generate the architecture council brief, the capability map readout, the scanner coverage attestation, the control catalogue rollout, the exception register summary, the framework coverage attestation, and the multi-year roadmap progress narrative from the live engagement records through AI-assisted reporting. The steering committee and the operations team read against the same record, so the architectural intent and the operational reality converge.
9. 9Read the recurring architecture council cadence from the append-only activity log. Every workspace event the architectural model touches lands on the log with the actor, the entity, the timestamp, and the action. Plan retention and CSV export keep the architecture decision trail reproducible across surveillance cycles, so the architecture council brief next quarter starts further ahead rather than from a fresh export.

Where the operating model the architect designs connects to the rest of the workspace

Most security operating models adopt SecPortal in three phases: bring every architectural workstream onto an engagement record so the blueprint, the capability map, the scanner inventory, and the roadmap live on the same record the operations team runs against; define the typed finding record and the scanner-to-finding pipeline so every source consolidates against the same record shape; and route the cross-team architecture through role-based access control, cross-framework compliance tracking, AI-assisted reporting, and the append-only activity log so the architecture council and the operations team read against the same source. The relevant feature, workflow, framework, and research pages explain each phase in detail.

• The engagement record model that anchors every architectural workstream is covered on the engagement management feature page, the typed finding record on the findings management feature page, and the versioned blueprint and decision-record attachment surface on the document management feature page.
• The scanner-to-finding pipeline architecture rides the code scanning feature page for SAST and SCA, the authenticated scanning feature page for DAST behind the login screen, the external scanning feature page for the verified perimeter, the scheduled scans feature page for the cadence layer, the bulk finding import feature page for the rest of the scanner estate, and the scan comparison and diff feature page for change-event semantics.
• The control catalogue and the cross-framework crosswalk ride the compliance tracking feature page, the AI-assisted programme report on the AI reports feature page, and the evidence collection architecture on the activity log feature page.
• The team and role architecture rides the role-based access control feature page, the multi-factor enforcement surface on the multi-factor authentication feature page, and the cross-team account model on the team management feature page.
• The exception governance architecture rides the finding overrides feature page for the eight-field decision chain, and the closure leg of the finding lifecycle rides the retesting workflows feature page.
• The audit fieldwork evidence pull workflow rides the audit fieldwork evidence request fulfilment use case, the cross-framework crosswalk workflow on the control mapping crosswalks use case, and the security tool consolidation workflow on the security tool consolidation use case.
• The vulnerability management programme maturity model that the multi-year capability roadmap reads against on the vulnerability management programme maturity model research, the cross-framework crosswalk economics on the multi-framework crosswalk economics research, and the security finding routing rule economics on the security finding routing rule economics research.
• The frameworks the control catalogue rides against on the ISO 27001 framework page, the SOC 2 framework page, the NIST CSF 2.0 framework page, the NIST SP 800-53 framework page, and the OWASP SAMM framework page.
• The enterprise security programme maturity narrative on the enterprise security programme maturity guide, the multi-team operating model on the multi-team security operations guide, and the security tool sprawl and consolidation guide on the security tool sprawl and consolidation guide.
• The architecture artefact set on the security program charter template, the vulnerability management program charter on the vulnerability management program charter template, and the routing rule design worksheet on the security finding routing rules design worksheet.

Where the security program architect role sits next to adjacent personas

Security program architects design the operating model behind the programme: the capability map, the record model, the scanner-to-finding pipeline architecture, the control catalogue, the evidence collection architecture, the team and role architecture, and the multi-year capability roadmap. The role sits next to the executive sponsor who carries the operating model to the board, the programme manager who runs the workstreams against the operating model, the security architect who runs design reviews on individual systems, the AppSec program lead who owns the AppSec capability inside the operating model, the vulnerability management lead who runs the per-finding queue against the operating model, the GRC and compliance lead who reads against the cross-framework crosswalk, and the security operations leader who runs the recurring cadence against the operating model.

If your function is the executive sponsor for the operating model and the board-level reporting that sits above the architecture, the SecPortal for CISOs and security leaders page covers the leadership tier that consumes the operating model the architect designs.

If your function is cross-team programme coordination and workstream execution rather than operating-model design, the SecPortal for security program managers page covers the programme coordination layer that operates the workstreams against the architecture.

If your function is per-system design review, threat modelling, and the control-to-system mapping rather than the cross-capability operating model, the SecPortal for security architects page covers the design-time architecture and threat modelling workflow.

If your function is AppSec capability ownership at programme scale, the SecPortal for application security program leads page covers the AppSec programme record model that rides the wider operating model the architect designs.

If your function is the per-finding queue against the operating model, the SecPortal for vulnerability management teams page covers the operator-side workflow that runs underneath the architectural design.

If your function is the recurring operations cadence that runs the operating model between forum cycles, the SecPortal for security operations leaders page covers the SecOps cadence that pairs scheduled scanning, severity-driven SLAs, exception governance, and the recurring reporting cadence on the same record.

If your function spans compliance evidence and audit coordination, the SecPortal for GRC and compliance teams page covers the audit-pack workflow that reads from the same engagement record the architect designs against.

SecPortal is built for security program architects who want the operating model they design and the operating model the workspace ships to be the same record rather than two artefacts the operations team rebuilds from each other on contact. Engagement records per architectural workstream, a typed findings record across every source pipeline, the scanner-to-finding pipeline as a workspace primitive, structured exception records with the eight-field decision chain, retesting workflows paired to the original finding, scan comparison and diff for change-event semantics, cross-framework compliance tracking across 21 frameworks, AI-assisted programme reporting, role-based access control with multi-factor authentication, and an append-only activity log on top. The architecture council, the steering committee, the vulnerability management team, the AppSec team, the GRC team, the cloud security team, the security engineering team, and the security operations leader all read against the same record the architect designs against.