Category: GRC & Compliance

DevSecOps vs SecDevOps: Choosing the Right Security Model for Your Organisation in 2026

April 25, 2026

Security in software development is no longer optional — but the model you choose to implement it makes a profound difference to both security outcomes and delivery velocity. Two approaches dominate current practice: DevSecOps, which weaves security continuously throughout the development pipeline, and SecDevOps, which places security architecture as the absolute prerequisite before any code is written. Understanding when each is appropriate is one of the key judgment calls a security architect or leader must make in 2026.

What Is DevSecOps? The Shift-Left Imperative

DevSecOps is a cultural and technical transformation that embeds security practices into every phase of the Software Development Lifecycle (SDLC) — from initial design through deployment and post-release monitoring. Its governing principle is straightforward: the earlier a vulnerability is detected, the cheaper and less disruptive it is to remediate.

NIST’s Secure Software Development Framework (SSDF), published as SP 800-218, provides the authoritative reference for DevSecOps implementation. It organises practices around four groups: Prepare the Organisation (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Organisations that align their pipelines to SSDF are implementing DevSecOps in a structured, auditable way.

The five core principles of DevSecOps are:

  1. Shift-Left Security: Developers scan their own code as they build it, reducing the gap between writing vulnerable code and fixing it from weeks to minutes.
  2. Automated Security in the CI/CD Pipeline: Every commit triggers automated SAST, DAST, SCA, and secrets scanning — no manual review required at every step.
  3. Shared Security Ownership: Developers, DevOps engineers, and security specialists collaborate, with security functioning as an enabler rather than a gatekeeper.
  4. Security as Code (SaC): Policies are codified in machine-readable form, ensuring every deployment automatically inherits correct security configurations.
  5. Continuous Monitoring: Real-time monitoring of live applications detects emerging threats and feeds insights directly into the next sprint.

What Is SecDevOps? Security-by-Design at Scale

SecDevOps takes a more rigorous architectural stance: no development begins until the security architecture is fully defined and validated. While DevSecOps brings security earlier into development, SecDevOps positions it before development starts entirely — in the planning and threat modelling phase.

This methodology is standard in regulated, high-stakes environments: defence, financial market infrastructure, healthcare, and critical national infrastructure — sectors where a single exploitable vulnerability carries severe legal, financial, or operational consequences.

The five defining characteristics of SecDevOps are:

  1. Secure-by-Design Architecture: Applications are engineered around strict security standards from inception. Security is not retrofitted; it is foundational.
  2. Security as Code — Automating Compliance: Firewall rules, access controls, and compliance checks are codified and applied consistently across all environments.
  3. Infrastructure as Code (IaC) — Hardened Environments: Pre-hardened infrastructure is provisioned through code, eliminating insecure manual configurations.
  4. Automated Governance and Regulatory Compliance: The system continuously validates itself against HIPAA, GDPR, ISO 27001, or APRA CPS 234 and halts workflows on violation detection.
  5. Embedded Security Expertise: Security professionals are core team members from day one — not consultants parachuted in at review gates.

Head-to-Head: When Each Model Wins

Dimension DevSecOps SecDevOps
Delivery velocity High — security accelerates delivery Moderate — thorough design phase upfront
Regulatory environment Consumer, SaaS, general enterprise Finance, defence, healthcare, critical infra
Risk tolerance Moderate — iterative risk reduction Low — zero-defect policy preferred
Security ownership Shared across dev, ops, security Security-led, top-down governance
Cost model Lower — leverages existing pipelines Higher — dedicated security architecture team
Cloud-native fit Strong — microservices, auto-scaling Strong — IaC and hardened provisioning

Choosing the Right Approach: A Practitioner’s Framework

Choose DevSecOps if your organisation operates in a competitive consumer market, values rapid feature delivery, runs on cloud-native infrastructure, or cannot justify a standalone security department for every development team.

Choose SecDevOps if you operate under APRA CPS 234, ISO 27001, PCI-DSS, or HIPAA obligations; process highly sensitive data; manage financial market infrastructure; or cannot accept the reputational and regulatory consequences of releasing software with known vulnerabilities.

The most mature organisations adopt a hybrid posture: applying SecDevOps rigour during the design and threat-modelling phase, then leveraging DevSecOps automation during execution. In financial market infrastructure — where I work — this hybrid model is increasingly the norm: architectural security gates upfront, automated pipeline controls throughout, and continuous monitoring post-deployment.

The Australian Context: APRA and ASIC Expectations

For Australian organisations, APRA CPS 234 (Information Security) mandates that entities maintain information security capabilities commensurate with the size and extent of threats to their information assets. This obligation extends explicitly to software development and third-party dependencies. The ASIC Cyber Resilience Good Practices guide (2023) similarly emphasises secure-by-design as a baseline expectation for regulated entities, particularly those operating financial market infrastructure.

Organisations that cannot demonstrate secure development practices in their third-party assessments and vendor questionnaires are increasingly being flagged as elevated risk. Whether you choose DevSecOps, SecDevOps, or a hybrid, the expectation is the same: security must be systematic, evidenced, and auditable.

References and Further Reading

  • NIST SP 800-218 — Secure Software Development Framework (SSDF), Version 1.1 (2022)
  • OWASP DevSecOps Guideline — owasp.org
  • APRA CPS 234 — Information Security (2019)
  • ASIC — Cyber Resilience Good Practices (2023)
  • Gartner, How to Integrate Security Into DevOps (2024)
  • CISA, Shifting the Balance of Cybersecurity Risk: Principles for Security-by-Design (2023)

The Golden Circle of Cybersecurity: Aligning Security Strategy with Business Value

April 24, 2026

In many organisations, cybersecurity is still perceived as a technical cost centre — a function that consumes budget, generates audit findings, and slows down projects. This perception is both inaccurate and damaging. When security is positioned correctly, it becomes a strategic enabler of business success: protecting revenue, sustaining customer trust, enabling digital transformation, and differentiating the organisation in competitive markets.

One of the most effective frameworks for communicating this alignment is Simon Sinek’s Golden Circle, applied to security strategy: Why, What, and How. It reframes security from a reactive control function into a proactive business value protector.

WHY: Protecting Business Value and Competitive Advantage

Every organisation’s security programme must begin with a clear articulation of purpose. Not “to comply with ISO 27001” — that is a mechanism, not a purpose. The genuine Why of cybersecurity is the protection of what the organisation values most: its revenue-generating processes, its customer data and the trust built around it, and its competitive differentiation.

Organisations that cannot articulate their security purpose at a business level consistently fail to secure adequate investment. Security becomes a cost centre precisely because it has not been positioned as a value protector. The 2024 Ponemon Institute Cost of a Data Breach Report found that the global average cost of a breach reached USD 4.88 million — a 10% increase from 2023. For organisations in financial services and healthcare, the costs are substantially higher when regulatory penalties and reputational damage are included.

The Why must also drive prioritisation. Not all assets carry equal business value. A mature security programme focuses its resources on protecting the assets whose compromise would most directly damage the organisation’s ability to operate, compete, and maintain stakeholder trust.

WHAT: Defining the Right Controls — Risk-Driven, Not Checklist-Driven

Once the purpose is clear, the next step is determining which controls are needed to protect it. This is where many organisations go wrong: they implement controls based on what auditors expect rather than what business risk requires. The result is a programme that passes assessments but fails to address the actual threat landscape.

A risk-driven control strategy organises controls into four categories:

  • Preventive Controls: Identity and Access Management (IAM), network segmentation, secure configurations, and endpoint hardening that reduce the probability of a breach.
  • Detective Controls: SIEM, threat intelligence platforms, user behaviour analytics (UEBA), and EDR that identify threats before they escalate.
  • Corrective Controls: Incident response plans, backup and recovery mechanisms, and crisis management frameworks that restore operations after an event.
  • Governance Controls: Policies, standards, risk registers, and reporting mechanisms that ensure decisions are made with accurate information and clear accountability.

NIST CSF 2.0 organises these into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. The addition of the Govern function in the 2024 update explicitly recognises that control effectiveness depends on clear accountability and strategic intent — not just technical implementation.

HOW: Enabling Through Technology, Process, and Culture

The How layer is where strategy is executed. It encompasses the technology stack, the processes that govern its use, and the culture that sustains it over time.

Technology enablement includes EDR, SIEM, cloud security platforms (CSPM, CWPP), DLP, and Zero Trust architecture components. Technology alone, however, does not produce security outcomes. It produces data — which must be acted upon by capable people operating within clear processes.

Process integration includes risk-based vulnerability management, continuous monitoring and threat hunting, incident response lifecycle management, and secure software development lifecycle (SSDLC) integration. Mature programmes automate as much of this as possible, reducing dependence on individual effort and enabling consistent outcomes at scale.

Culture and people represent the most under-invested layer in most security programmes. Security awareness training that changes behaviour — not just achieves compliance — requires understanding of cognitive biases, social engineering techniques, and the psychology of decision-making under uncertainty. Research by the Verizon DBIR consistently identifies human factors as contributors to the majority of breaches, underscoring that technical controls alone are insufficient.

Bringing It Together: Security as a Strategic Differentiator

When the Golden Circle is applied consistently, the result is a security programme that earns and sustains executive confidence, secures appropriate investment, and produces measurable risk reduction. More importantly, it positions the security function as a strategic partner rather than a compliance overhead.

In the Australian context, this alignment is increasingly examined by APRA, ASIC, and the Australian Signals Directorate (ASD). The Essential Eight Maturity Model, ASD’s baseline control framework, rewards organisations that approach security strategically — with documented intent, measured outcomes, and continuous improvement cycles.

Organisations that invest in aligning their security strategy to business value are not just better protected. They are better positioned to grow.

References and Further Reading

  • Sinek, S. (2009). Start With Why. Portfolio/Penguin.
  • NIST Cybersecurity Framework 2.0 (February 2024)
  • Ponemon Institute — Cost of a Data Breach Report 2024
  • Verizon — Data Breach Investigations Report 2024
  • ASD — Essential Eight Maturity Model (2023)
  • APRA CPS 234 — Information Security

ISO/IEC 42001:2023 Explained: The AI Management Standard Every Security Professional Needs to Understand

April 21, 2026

Artificial intelligence is growing fast in business — and regulators, boards, and customers are increasingly demanding that organisations demonstrate they manage it responsibly. A 2024 McKinsey survey found that fewer than one in four organisations have a mature AI governance function, despite the majority expecting AI-specific regulation within two years. ISO/IEC 42001:2023 — the world’s first international standard for AI Management Systems (AIMS) — provides the governance architecture organisations need to close that gap.

For security professionals holding CISSP, CCSP, or AAISM credentials, understanding ISO 42001 is no longer optional. AI systems introduce risk categories that traditional information security frameworks were not designed to address: model bias, adversarial attacks, data poisoning, membership inference, and system prompt injection. ISO 42001 is the standard that organises governance around these AI-specific risk vectors.

What Is ISO/IEC 42001?

ISO 42001 is a management system standard — structurally similar to ISO 27001 (information security) and ISO 9001 (quality management). It provides a framework for organisations that develop, provide, or deploy AI systems to establish, implement, maintain, and continuously improve an Artificial Intelligence Management System (AIMS). It follows the standard High-Level Structure (HLS) used across all ISO management system standards, making integration with existing ISO 27001 implementations more straightforward.

The standard covers the full AI lifecycle: design, development, deployment, operation, monitoring, updates, and retirement. It applies regardless of organisation size, sector, or AI maturity level.

Clause-by-Clause: The Governance Architecture

Clauses 1–3 (Scope, References, Definitions) establish the standard’s boundaries, reference ISO/IEC 22989 for AI terminology, and define key terms including AI management system, risk, data quality, and AI impact assessment. Alignment on terminology is foundational — it ensures that technical, legal, and business teams operate with a shared vocabulary during audits and governance reviews.

Clause 4 (Context of the Organisation) requires organisations to identify internal and external stakeholders, understand their expectations, and define the scope of the AIMS with precision. Is the organisation using AI for customer service automation or for clinical decision support? The risk profile differs dramatically, and the scope definition must reflect that.

Clause 5 (Leadership) assigns explicit accountability to leadership for AI governance. Senior management must establish an AI policy, assign clear roles and responsibilities, and demonstrate active oversight — not passive sign-off. This is consistent with the governance expectations of APRA CPS 234 and ASIC’s technology risk guidance, both of which require board-level accountability for material technology risks.

Clause 6 (Planning) is where risk management becomes operational. Organisations must identify AI-specific risks — including model bias, adversarial manipulation, unintended outputs, and data quality failures — assess their likelihood and impact, and plan mitigating controls. Clause 6 also requires setting AI objectives with measurable targets and an explicit mapping against Annex A controls.

Clauses 7–8 (Support and Operation) ensure that the AIMS is resourced and executed: skilled personnel, training, documentation, and operational controls across the AI lifecycle. Incident response plans for AI system failures and regular AI impact assessments are required at the operational level.

Clause 9 (Performance Evaluation) drives continuous measurement — tracking model performance, compliance status, and incident metrics — through internal audits and management reviews. This is the evidence layer that satisfies auditors and regulators.

Clause 10 (Improvement) closes the loop: root cause analysis of nonconformities, corrective action, and systematic improvements to keep the AIMS current as AI technology and threat landscapes evolve.

Annex A: The 38 AI Controls

Annex A lists 38 recommended controls across risk areas including data quality, bias management, transparency, human oversight, adversarial robustness, and incident management. Organisations are not required to implement all 38, but they must review each one and document their applicability decisions in a Statement of Applicability — the same approach used in ISO 27001 implementations. Auditors will examine both the controls implemented and the rationale for any exclusions.

ISO 42001 and the AAISM Certification

ISACA’s Advanced in AI Security Management (AAISM) certification — which I hold — aligns closely with ISO 42001’s risk governance architecture. AAISM prepares professionals to assess AI risk from an auditor’s perspective: evaluating membership inference controls, differential privacy implementations, model integrity verification, and AI system resilience. The two credentials complement each other naturally: ISO 42001 provides the management framework; AAISM provides the security-specific assurance competency.

Why This Matters for Australian Organisations

Australia’s AI regulatory environment is evolving rapidly. The Australian Government’s Safe and Responsible AI framework (2023) and CSIRO’s AI Ethics Framework both emphasise transparency, accountability, and human oversight — principles that map directly to ISO 42001’s governance architecture. Organisations that establish ISO 42001-aligned AI governance now will be significantly better positioned when mandatory AI governance requirements are formalised.

References and Further Reading

  • ISO/IEC 42001:2023 — Information Technology, Artificial Intelligence, Management System
  • ISO/IEC 22989:2022 — AI Concepts and Terminology
  • ISACA — AAISM Certification Body of Knowledge (2024)
  • NIST AI Risk Management Framework (AI RMF 1.0) — nist.gov
  • Australian Government — Safe and Responsible AI in Australia (2023)
  • McKinsey Global Survey on AI (2024)
  • OWASP LLM Top 10 (2024) — owasp.org

Microsoft’s Forced Windows 11 24H2 Rollout: Security Implications for Enterprise IT Teams

April 4, 2026

Microsoft has initiated an automated, machine-learning-driven rollout to upgrade unmanaged Windows 11 devices to version 24H2. While the security improvements in 24H2 are substantive, the forced nature of this rollout creates operational, compliance, and security governance challenges that enterprise teams must address proactively.

What Is Changing and Why It Matters

Windows 11 24H2 introduces several significant security enhancements: improved Smart App Control capabilities, expanded Windows Protected Print Mode, enhanced Credential Guard defaults, and Rust-based kernel security improvements that reduce memory safety vulnerabilities. For organisations still on earlier Windows 11 builds, these improvements are meaningful — particularly the kernel hardening changes that address a class of vulnerabilities that have been actively exploited by APT actors in recent years.

However, Microsoft’s use of ML-based automatic upgrade targeting for unmanaged devices introduces risks of its own. Devices that receive the upgrade outside of a managed change management process may:

  • Experience compatibility issues with legacy enterprise applications not yet validated against 24H2.
  • Bypass configured Windows Update for Business Group Policies in misconfigured environments.
  • Receive the upgrade during production hours, causing unexpected reboots and operational disruption.
  • Introduce configuration drift if 24H2-specific security defaults differ from organisational baselines.

Security Governance Considerations

For organisations operating under APRA CPS 234, ISO/IEC 27001:2022, or ASD Essential Eight requirements, uncontrolled OS upgrades on endpoints represent a configuration management risk. The ASD Essential Eight’s Application Control and Patch Operating Systems controls both depend on known, validated endpoint states. An automated OS upgrade that has not been through the organisation’s change management process violates the foundational assumption of those controls: that the environment is known and intentionally configured.

Organisations using Microsoft Endpoint Manager (Intune) or WSUS for update management should verify that their deferral policies are applied correctly and that the 24H2 automatic rollout is not bypassing them. The ML-based targeting reportedly applies to devices Microsoft determines are “ready for upgrade” — but the criteria used by Microsoft’s algorithm may not align with organisational readiness criteria.

Practical Steps for Security and IT Teams

  1. Audit endpoint compliance status: Identify all devices currently on Windows 11 builds prior to 24H2. Determine which are managed versus unmanaged.
  2. Verify Update policy enforcement: Confirm that Windows Update for Business deferral settings are correctly applied and are not being overridden.
  3. Validate CIS Benchmark alignment: Microsoft has published a CIS Benchmark for Windows 11 24H2. Review the delta from the prior benchmark and identify any new security defaults that require explicit configuration.
  4. Test application compatibility: Run compatibility validation against business-critical applications before allowing the 24H2 upgrade to proceed in production.
  5. Update your CIS L1/L2 baseline documentation to reflect 24H2 configurations, particularly for Credential Guard, Smart App Control, and kernel protection settings.

The Broader Observation: Vendor-Driven Change Management Risk

This event illustrates a recurring challenge in enterprise security: the tension between vendor-driven update cadences and organisational change management processes. Cloud-era software increasingly assumes continuous, automatic updates — a model that conflicts with the controlled, evidence-based change management that security governance frameworks require.

The resolution is not to resist updates — prompt patching is a core security control. It is to ensure that the managed update process is fast enough that unmanaged devices represent a genuinely small population, and that the governance frameworks acknowledge and manage the risk of vendor-initiated changes.

References and Further Reading

  • Microsoft — Windows 11 24H2 Release Notes and Security Changelog
  • CIS Benchmark for Windows 11, Release 24H2 — cisecurity.org
  • ASD Essential Eight Maturity Model — Patch Operating Systems (2023)
  • Microsoft Learn — Windows Update for Business Configuration
  • NIST SP 800-128 — Guide for Security-Focused Configuration Management