7.2 Security
Security Guide for GovStack Implementations
Introduction and purpose
The earlier GovStack Security Requirements were extensive and detailed. The CFR architecture still needs a dedicated security guide because security is not “a feature” - it is the result of consistent decisions across building blocks, integration patterns and operations.
This guide is written for digital government leaders and for teams implementing GovStack. It focuses on the practical security architecture that makes a GovStack platform trustworthy at national scale:
Security built in during development (build-time)
Security enforced during deployment and operations (run-time)
Shared security capabilities that all building blocks can rely on instead of re-inventing controls in each product
This guide complements the GovStack Cross-Functional Requirements (CFR). The govstack-cfr-security requirements define the baseline controls every building block must meet (transport security, secure configuration, secure logging, secure coding and review, security testing gates, credential handling, isolation, vulnerability scanning and patching, incident response, compliance readiness, etc.). This guide explains how to implement a coherent security architecture across GovStack components so those baseline controls are consistently achieved across the platform.
Frameworks and standards to consider
NIST Cybersecurity Framework and NIST 800-171 - useful structure and coverage. The five NIST functions (Identify, Protect, Detect, Respond, Recover) organize this guide.
ISO/IEC 27001 - helps frame governance, risk management and audit readiness.
Privacy by Design - personal data must remain private and only shared with a clear legal basis and authorization. Treat logs and operational data as sensitive too.
How to use this guide
This is a guide, not a compliance checklist. Use it to make a few platform decisions early and then apply them consistently:
Decide where identity and access are enforced.
Decide where APIs are exposed and protected.
Decide how cross-organization exchange is secured.
Decide how you detect security issues and how you coordinate response across agencies and vendors.
Decide what “good enough” looks like in year one and what must improve over time.
A common failure mode in digital government is “everyone implements security their own way.” GovStack is designed to avoid that by standardising shared components and patterns.
Security governance and operating model
Security consistency at national scale is primarily a governance problem - not a tooling problem. Establish clear ownership and decision rights early so platform security decisions are applied consistently across agencies, vendors and building blocks.
Define roles and decision rights
it is recommended to have named owners for these platform responsibilities (one role can share multiple responsibilities, but should be designed as scalable in case roles should be separate):
Platform security owner - accountable for cross-platform security architecture and for resolving cross-agency security conflicts.
IAM and identity governance owner - accountable for authentication and authorization policies, role and attribute models and joiner-mover-leaver processes.
API exposure and gateway policy owner - accountable for how APIs are published, protected and deprecated including internal vs external policy separation.
Cross-organisation exchange owner - accountable for Information Mediator trust rules, organisation-level permissions and data sharing constraints.
Data owners - accountable for classification, lawful basis for sharing and approval of high-risk access and data release.
Security monitoring and incident response owner - accountable for detection coverage, triage, incident coordination and evidence retention.
Platform operations owner - accountable for secure configuration baselines and for preventing configuration drift across environments.
Write down which decisions each role can make unilaterally and which require multi-party approval.
Establish approval paths for high-risk access and data sharing
Define explicit approval rules for:
privileged roles
cross-organisation access entitlements
access to sensitive datasets and operational telemetry (logs, traces, dashboards)
exceptions to platform security patterns (time-boxed and documented)
Ensure approvals are auditable: who approved, what was approved, why it was approved and when it expires.
Minimum governance artifacts to keep government digital platform coherent
Maintain a small set of living artifacts that every team and vendor must follow:
platform security principles and standard patterns (enforcement points, trust boundaries and acceptable integrations) - including GovStack cross-functional requirements
data classification model and handling rules
access model and entitlement management rules (including recertification for high-risk access)
API exposure policy (internal vs external, publication criteria and deprecation discipline)
vulnerability management ownership model (who fixes what and how priority is set)
incident response playbooks including communications and evidence handling
security exception process with expiry and review
Keep these artifacts lightweight but enforce them consistently. If a rule affects interoperability or platform trust, it must be captured here and applied across all implementations.
Identify - Managing identity, authentication and authorization
Identity is where government systems most often fail in practice - not because of missing technology but because identity governance is weak and inconsistent across systems.
Centralised authentication and authorization
Baseline requirements for access control, authentication, least privilege and token handling are defined in govstack-cfr-security. This section focuses on how to implement them as a shared platform capability.
Central IAM as a platform service - Treat IAM as a core national platform service, not as a project-level component. It should support citizen identity, government workforce identity and system-to-system identities.
Consistent enforcement points - Standardise where authorization is enforced:
at the API gateway for external access
at an internal integration boundary for service-to-service calls
at the Information Mediator boundary for cross-organisation exchange
Role-based access control (RBAC) as the baseline - Use RBAC to manage permissions at scale across ministries and agencies.
Policy-based access where needed - For many government services RBAC alone is not enough. Add policy rules where context matters, for example consent status, jurisdiction, purpose of use, sensitivity level, organisational mandate and service channel. Keep policy rules central so they do not fragment across building blocks.
Provisioning and de-provisioning as an operating process - Define processes for creating, updating and revoking identities and access rights. Ensure these processes integrate with IAM and with any API management layer.
Multi-factor authentication and credential assurance
Baseline requirements for credential handling and secure practices are defined in govstack-cfr-security. This section focuses on leader decisions and operating models.
MFA for privileged access as a default - Apply MFA to administrative roles and high-risk actions consistently across the platform.
Match assurance to risk - Not every service needs the highest assurance. Define tiers (low, medium, high) and apply stronger authentication and checks where consequences are higher.
Digital ID and certificates where they add value - Use certificates and signing where you need non-repudiation or high assurance, for example official approvals, high-risk administrative actions and signing workflows. Manage certificates as an operational capability, not as a one-time setup.
Audit, accountability and evidence
Baseline requirements for logging and monitoring security events are defined in govstack-cfr-security. This section focuses on what to capture and how to use it.
Identity and access event model - Standardise what you log across IAM, gateways and building blocks:
authentication success/failure and step-up events
permission denials and privilege changes
creation, revocation and reactivation of accounts and service credentials
Governance and accountability - Decide who reviews privileged access grants, who approves cross-organisation access and who owns the evidence during audits and investigations.
Non-repudiation as a targeted control - Apply non-repudiation to high-risk government actions, not to everything. Use it to support dispute handling and legal defensibility where required.
Device management
Where building blocks interact with physical devices (biometric capture devices, kiosks, field devices), define secure device lifecycle practices:
controlled registration and de-registration
secure configuration baselines
ownership for device operations and incident handling
clear rules for lost, stolen or compromised devices
Managing user access effectively
These practices are key to stopping common real-world attack paths:
Remove orphaned and stale accounts - Detect and remove accounts that no longer have an owner, for example staff who left an agency, expired contractors or retired service accounts.
Verify revocation works - When access is removed, verify that removal is enforced across IAM, gateways and dependent systems.
Safe self-service - Enable secure self-service password resets and account recovery to reduce helpdesk load. Treat recovery flows as high-risk and monitor them accordingly.
Periodic recertification for high-risk access - Review privileged roles and cross-organisation entitlements periodically. This is one of the most effective governance controls in government environments.
Protect - Securing data, services and infrastructure
Baseline requirements for transport security, cryptography and secure gateways are defined in govstack-cfr-security. This section focuses on platform patterns that make those requirements consistent across GovStack implementations.
Data protection and sovereignty
Data classification and handling rules - Define a clear data classification model and apply it consistently across building blocks, registries and operational tooling.
Minimal data exposure - Release only what is required for the transaction. Avoid copying registry datasets between agencies unless there is a strong governance reason.
Data sovereignty and residency - Plan early for jurisdiction constraints because they affect cloud strategy, vendor selection and operating model.
Key and certificate management as an operational capability
Key rotation policy requirements are already defined in govstack-cfr-security. This section focuses on operating discipline.
Central secrets and key management - Centralise keys, certificates and credentials with clear ownership, auditability and access controls.
Effective revocation - Ensure revocation actually blocks access across gateways and downstream systems, not only in a central directory.
Emergency access - Define controlled “break-glass” access for outages and incidents, with time limits, strong logging and post-incident review.
Network and infrastructure security
Isolation and containment requirements are defined in govstack-cfr-security. This section focuses on how leaders should structure environments.
Segmentation that teams can operate - Define zones (public, edge, platform, building blocks, data and admin) and enforce them consistently.
Isolation for critical registries and core services - Put critical registries and the IAM core into more restricted environments to reduce blast radius.
Multi-tenancy controls - If multiple agencies share the platform, enforce isolation in both the data plane and management plane.
Reduce configuration drift - Prefer repeatable, centrally controlled deployment and configuration management so production environments do not diverge from tested baselines.
Observability and monitoring
Logging and monitoring security events requirements are defined in govstack-cfr-security. This section focuses on platform implementation.
Central security visibility - Make sure you can answer during an incident: what happened, who did it, what changed and what else was affected.
Correlation across the platform - Ensure security events can be correlated across IAM, gateways, Information Mediator and key building blocks.
Protect operational data - Treat logs, traces and dashboards as sensitive systems with access controls and retention rules.
API management and gateway
Secure API gateway requirements are defined in govstack-cfr-security. This section focuses on a GovStack-ready gateway operating model.
Separate internal and external gateways - Use different policy sets for citizen/partner access and for internal integration traffic.
Centralised policy management - Define access policy once and apply it consistently across gateways and APIs.
Traffic controls as governance - Use rate limits and quotas to prevent accidental platform exhaustion by a single consumer or agency. This supports stability and fairness across government.
API lifecycle discipline - Apply versioning and deprecation rules. Many security incidents start as unmanaged API change.
Legacy integration responsibly - Where protocol or payload translation is needed (for example XML to JSON or SOAP to REST), implement it in controlled integration layers and ensure it is governed and monitored.
IAM and authorization services
The platform IAM and authorization capability coordinates authentication and authorization across building blocks. It should be treated as a shared capability with clear responsibilities:
applications use IAM to obtain user permissions and apply them consistently
local building block calls use service-level credentials by default and only forward user context when there is a clear reason
cross-organisational calls via Information Mediator follow organisation-level authorization and explicit rules for data sharing purpose, scope and legal basis
Detect, respond and recover - Operational security
Baseline requirements for vulnerability scanning and patching, disaster recovery and incident response are defined in govstack-cfr-security. This section focuses on the operational model that makes them work across a national platform.
Vulnerability management that drives remediation
Central coverage - Use central scanning and tracking so coverage does not depend on each team’s maturity.
Prioritisation and ownership - Vulnerabilities must be prioritised, assigned to owners and tracked to closure. Dashboards without accountability do not reduce risk.
Fast response to new vulnerabilities - Reduce time from disclosure to remediation, especially for gateway, IAM and registry components.
Cloud security posture management (CSPM)
Ensure CSPM covers the full inventory of cloud resources, not only compute and networking.
Ensure findings lead to actions and improved configurations, not only reports.
Tune alerts to avoid fatigue so teams do not ignore the tool.
Platform security monitoring
Focus monitoring on identity misuse, privilege changes, abnormal access patterns and unexpected configuration drift.
Ensure events from IAM, gateways and core building blocks can be correlated to support investigations and rapid containment.
Threat mitigation and social engineering
Maintain regular training and clear reporting channels for suspected phishing and impersonation.
Combine training with practical technical controls and monitoring for account takeover patterns.
Require vendors supporting the platform to demonstrate how they mitigate and respond to social engineering risks.
Denial of service resilience
DoS prevention and related controls are covered in the legacy security requirements and should be addressed operationally in GovStack deployments.
Protect at the edge with filtering and capacity controls.
Use gateway traffic controls to preserve platform stability.
Maintain runbooks for graceful degradation to keep core services alive.
Incident response and business continuity
Incident response and disaster recovery requirements are defined in govstack-cfr-security. This section focuses on ensuring readiness.
Runbooks for shared components - Maintain runbooks for IAM, gateways, Information Mediator and critical registries.
Realistic exercises - Use a staging or sandbox environment close enough to production to run meaningful simulations.
Registry recovery capability - Ensure key registries support point-in-time restore and that restore is practiced, validated and auditable.
Automation during incidents - Where safe, automate protective actions such as temporary throttling, blocking known-bad sources and isolating affected components.
Build-time security (DevSecOps)
Baseline requirements for security testing gates, secret handling, vulnerability scanning in CI/CD and secure coding practices are defined in govstack-cfr-security. This section focuses on GovStack-specific build-time controls that reduce integration risk.
Secure onboarding of DPGs and existing products
Treat onboarding as both a functional integration and a security hardening step.
Ensure credentials are stored and managed safely and ensure platform monitoring and gateway controls apply equally to onboarded products.
Require evidence that vendors patch vulnerabilities and support incident response expectations.
API contract discipline
Treat API specifications as governance artifacts.
Require versioning and review of API changes because many privacy and security failures begin as “small” API changes.
Ensure API behaviour remains consistent with published contracts across environments.
Conclusion
GovStack implementations earn trust when security is consistent across the platform and when operations can detect issues early and recover fast. The govstack-cfr-security requirements define the baseline controls. This guide describes the platform architecture and operating model that make those controls achievable in practice across identity, gateways, cross-organisation exchange, infrastructure and incident response.
Treat this as a practical starting point. The leadership task is to ensure the platform applies shared patterns and shared controls so security is not left to individual projects or vendors.
Last updated
Was this helpful?