For security architects
who own secure design and the control-to-architecture mapping

A security architecture platform built around the live engagement record

Security architects own threat models, architecture and design reviews, control-to-architecture mapping, reference architectures, and the evidence that the system shipped against the model the architecture committee signed off. The work spans secure-by-design intake for new services, recurring design reviews for changes that cross trust boundaries, threat modelling sessions, control narrative authoring against ISO 27001 Annex A and SOC 2 Trust Services Criteria and NIST SP 800-53 and OWASP ASVS and PCI DSS and NIST SP 800-207 Zero Trust, AI and ML system review intake, and the audit-evidence pull at surveillance time. Most programmes carry this work in a Confluence space, a recurring meeting calendar, a Slack channel, a Word folder of threat models, a spreadsheet for the review queue, a deck for the architecture committee, and a separate deck for the audit committee, and pay the cost in reconciliation hours each cycle and in residual risk between cycles.

SecPortal gives in-house security architects one workspace for engagement records per review, document management for threat models and architecture diagrams and decision records, findings management with CVSS 3.1 calibration that turns threat model output into a testable backlog, compliance tracking that maps a single architectural decision against multiple frameworks at once, authenticated DAST and code scanning that pair design decisions to runtime evidence, AI-assisted committee reporting that regenerates summaries from the live record, and an append-only activity log that ties the trail together. The architecture review reads from one record rather than from a deck, a wiki, a spreadsheet, and a folder of PDFs.

Capabilities security architects use day to day

How security architects operate review and evidence inside SecPortal

An architecture review function that holds up under audit and incident review operates on a small set of disciplines. Threat modelling, control mapping, design decisions, and post-build evidence inherit each one rather than carving out a parallel operating model per artefact.

From design review to post-build evidence, on one engagement record

The architecture review loop is open the engagement, run the threat model, map controls, pair the design decision to runtime evidence, hand off to engineering, and report to the committee. SecPortal runs a single workflow that the architect, the reviewer, the security champion in engineering, the compliance owner, and the security leader can all work against without re-keying state into another tool.

1. 1Open an engagement against the architecture review, the design review, the threat model exercise, or the reference architecture publication. Scope the review, name the panel, attach the diagram and the data-flow overview as documents, and capture the misuse cases and the trust boundary set on the engagement record. The review queue reads from one workspace from the first cycle.
2. 2Run the threat model and land the output as findings on the same engagement record. Each STRIDE category, abuse case, or trust-boundary violation that fails review becomes a finding with an auto-calculated CVSS 3.1 vector, severity, evidence, owner, and remediation status. The 300+ remediation template library populates concrete guidance for each class of issue.
3. 3Map the architectural decisions and the open findings against the relevant control sets through compliance tracking. ISO 27001 Annex A, SOC 2 Trust Services Criteria, NIST SP 800-53 control families, OWASP ASVS verification levels, PCI DSS requirements, NIST CSF 2.0 functions, and NIST SP 800-207 Zero Trust principles coexist on the same record, so one mapping produces multiple coordinated audit packs.
4. 4Pair the design decision to runtime evidence. Authenticated DAST against the deployed service, SAST and SCA from connected GitHub, GitLab, or Bitbucket repositories via OAuth, and external scanning across the verified perimeter run on the same engagement record as the architecture review. The scan diff endpoint surfaces new, fixed, and unchanged findings between runs so drift detection is a record event rather than a manual export-and-compare exercise.
5. 5Hand the engagement record to engineering through role-based access control and the branded client portal. Security champions read the review state, the threat model output, the severity per finding, and the remediation guidance from the same record the architect operates on rather than from a ticket comment thread that loses the trust boundary context.
6. 6Generate the architecture committee summary, the steering group deck, the audit committee report, or the regulator submission from the live engagement record through AI-assisted reporting. The committee reads a controlled document, the architect edits drafts rather than writes the deck from blank, and the audit trail follows the document set rather than the meeting calendar.

Where the architecture view connects to the rest of the workspace

Most architecture functions adopt SecPortal in three phases: bring the design review queue and the threat model output onto one engagement record so the backlog is testable, layer in control mapping across ISO 27001, SOC 2, NIST, OWASP ASVS, PCI DSS, and Zero Trust so a single architectural decision satisfies multiple audit packs, then pair design decisions to runtime evidence through authenticated DAST, code scanning, and external scans on the same record so drift is observable rather than asserted at audit time. The relevant feature, workflow, framework, and blog pages explain each phase in detail.

• The engagement record model that anchors every review is covered on the engagement management feature page, the findings repository that turns threat model output into a testable backlog on the findings management feature page, and the diagram, threat model, and decision-record attachment surface on the document management feature page.
• The multi-framework control mapping a single architectural decision rides is covered on the compliance tracking feature page, the AI-assisted committee summary and decision-record export workflow on the AI reports feature page, and the audit-grade record of every review event on the activity log feature page.
• The runtime-evidence side of the architecture record sits on the authenticated scanning feature page, the code-side validation through the Git provider on the code scanning feature page, and the scheduled runs and diff-aware drift detection on the continuous monitoring feature page.
• The security-onboarding intake that sits in front of the first design review on the new application security onboarding use case, the cross-framework crosswalk workflow that anchors one mapping against multiple frameworks on the control mapping crosswalks use case, and the SDLC handoff to engineering on the SDLC vulnerability handoff use case.
• The reference architecture for Zero Trust is anchored on the NIST SP 800-207 framework page, the broader Zero Trust implementation lifecycle on the Zero Trust Architecture implementation guide, and the verification-level model that architects map application reviews against on the OWASP ASVS framework page.
• The secure-by-design principles set that grounds the review queue on the CISA Secure by Design framework page, the design-gate artefact that walks identity, network, data, authorisation, secrets, supply chain, observability, resilience, and decommissioning across the whole system on the security architecture review template, the threat model template artefact for the per-element STRIDE enumeration on the threat model template, and the practitioner threat modelling walkthrough on the threat modelling guide.

For architects evaluating against design-time, code-time, and runtime adjacencies

Architects evaluating consolidation tend to compare a workspace that records the review against a Confluence-plus-spreadsheet operating model, against an ASPM aggregator that sits above code-time scanners, and against an SCM-anchored code-graph platform. The detailed side-by-side comparisons cover what each shape covers and where it stops.

• The SecPortal vs spreadsheets comparison covers the gap between a review queue carried on a shared sheet and an engagement record with structured findings, document management, control mapping, and an immutable activity trail.
• The SecPortal vs ArmorCode comparison covers the trade-off between an ASPM aggregation layer above an existing scanner stack and a workspace where authenticated DAST, code scanning, external scans, the engagement record, and the architecture review all share one platform.
• The SecPortal vs Cycode comparison covers the SCM-anchored code-graph ASPM shape against a workspace where the architecture review record, the threat model output, and the post-build runtime evidence sit on the same engagement.
• The SecPortal vs DefectDojo comparison covers a self-hosted findings hub against a managed delivery workspace with engagement records, authenticated scanning, encrypted credential storage, AI reporting, and the branded client portal that engineering teams read from.

SecPortal is built for security architects who want one workspace for the verify-review-map-pair-handoff-report loop: engagement records per review, threat model output as testable findings, multi-framework control mapping, runtime evidence from authenticated DAST and code scans on the same record, AI-assisted committee reporting, role-based access for engineering and audit, multi-factor authentication, and an append-only activity log. Engineering gets a clearer signal on the design decisions they are building against, security leadership gets a defensible posture between reviews, compliance gets reproducible evidence across frameworks, and the architecture function stops being a parallel operating model the rest of security has to reconcile.

If your function sits closer to programme-wide leadership and board-level reporting than to the design review queue itself, the SecPortal for CISOs and security leaders page covers the programme-level reporting workflow that sits on top of the architecture record without rebuilding a deck every quarter.

If your function is application security inside engineering rather than cross-cutting architecture review, the SecPortal for application security teams page covers the DAST, SAST, SCA, and pentest finding consolidation that sits downstream of the architecture review.

If your function is product security with PSIRT-style intake and security champions inside engineering, the SecPortal for product security teams page covers the security review intake, the champions portal, and the disclosure lifecycle that sit alongside the architecture review function.

If your function spans compliance evidence and audit coordination more than secure design itself, the SecPortal for GRC and compliance teams page covers the audit-pack workflow that reads from the same engagement record the architecture function operates on.