This document (Master Baseline Framework) defines the strategic framework — what Netier aims to achieve, which frameworks apply, and at what tier. For prescriptive configuration details (exact settings, policies, and deployment instructions per technology), see the companion Netier Technical Configuration Framework.
1. Executive Summary & Strategy
This document serves as the overarching Technical and Operational Baseline for Netier. It establishes a unified "Gold Standard" based on the Australian Signals Directorate (ASD) Information Security Manual (ISM) and Essential Eight (E8) Maturity Level 3.
From this peak standard, configurations are scaled into productised tiers (Essential, Professional, Enterprise) to provide clients with a secure-by-design baseline and a clear pathway to higher regulatory compliance. This framework governs all evidence gathering and tooling deployments (e.g., Netier Compliance Engine (planned — ISM scanner operational), NinjaOne).
2. Master Compliance & Framework Mapping
All technical controls and operational policies detailed in this baseline trace back to the following regulatory and security frameworks:
OS Hardening: Apply CIS/ASD ISM hardened baselines via Intune/GPO (e.g., disable LLMNR, SMBv1).
Execution Control: Implement Application Control (AppLocker/WDAC) restricting execution to trusted publishers/paths. Block macro execution from the internet globally.
Vulnerability Management: Automated OS and 3rd-party patching via NinjaOne (SLA: Critical within 48h).
Threat Defense: Deploy advanced EDR integrated with centralized SIEM for active isolation and threat hunting.
* Enforce DMARC at p=reject for all managed domains.
* Strict SPF and DKIM alignment configuration.
* Inbound Advanced Threat Protection (ATP) and AI-driven phishing filtering.
Web Asset Posture (Cloudflare, Speedtest, PageSpeed):
* Enforce Cloudflare Web Application Firewall (WAF) in strict block mode for public assets.
* Mandatory TLS 1.2+ (TLS 1.3 preferred) for all web traffic.
* Continuous monitoring of web performance (PageSpeed) and network latency (Speedtest) to ensure Operational Level Agreements (OLAs) are met.
4. Operational Policies & Governing Plans
The technical controls above are orchestrated and maintained through the following foundational plans. (Note: Automated gathering of evidence for these plans will be integrated into the Netier Compliance Engine toolchain — planned; external ISM scanner operational, full evidence automation in development).
4.1 Incident Response Plan (IRP)
Framework References:NIST IR, ISO 27001 (A.16), SOCI Act.
Defines Netier's procedures for detecting, classifying, responding to, and recovering from security events (e.g., ransomware, unauthorized access).
Includes mandatory reporting timelines to the ASD (via ACSC) and OAIC (Privacy Act).
Vendor risk assessment protocols focusing on third-party SaaS and hardware providers.
Addresses data sovereignty risks (particularly US-based SaaS tools) and delineates the Shared Responsibility Matrix between Netier, vendors, and clients.
5. Standard Operating Procedures (SOPs)
Each technical baseline and operational plan is supported by detailed, step-by-step SOPs that engineers follow during deployment and maintenance. SOPs are maintained in the SOPs/ directory.
Purpose: This document serves as the master index and prescriptive configuration guide for every technology in the Netier MSP stack. It dictates the exact settings, policies, and configurations required to meet the Netier "Gold Standard" (ISM/Essential Eight ML3) and defines how those settings scale down across the Essential, Professional, and Enterprise deployment tiers.
>
Relationship to Master Baseline: The Netier Master Baseline Framework defines the strategic framework and compliance mapping. This document provides the prescriptive, technology-specific configurations that implement that strategy.
* Block sign-ins from high-risk locations/anonymous IPs.
* Require compliant or hybrid-joined devices for access to SharePoint/OneDrive (Professional/Enterprise tiers).
Entra ID Roles: Limit Global Administrators to < 5. Use Privileged Identity Management (PIM) for Just-In-Time (JIT) access (Professional/Enterprise Tier).
Tenant Restrictions: Restrict cross-tenant access to prevent data exfiltration to unmanaged tenants.
2.2 Defender for Office 365
Anti-Phishing: Strict mode enabled. Impersonation protection active for all VIPs and internal domains.
Safe Links: Enabled with "Do not track user clicks" unchecked to allow for audit trails.
Safe Attachments: Enabled for Email, SharePoint, OneDrive, and Teams. Dynamic Delivery configured for email attachments.
Zero-Hour Auto Purge (ZAP): Enabled for spam, phishing, and malware.
DKIM/DMARC/SPF:
* SPF hard fail (-all).
* DKIM signing enabled for all primary and alias domains.
Primary tool: ThreatLocker (deployed on all managed endpoints). Where ThreatLocker is not deployed (e.g., air-gapped environments, client policy restrictions), use AppLocker (Windows Pro/Enterprise) or WDAC (Windows Defender Application Control) as the application control mechanism. The same default-deny policy intent applies regardless of tooling.
Mode: Default Deny (Ringfencing active).
Allowlisting: Based on path, publisher (certificate), and hash.
Ringfencing:
* PowerShell, Command Prompt, and cscript.exe restricted from interacting with network shares and downloading executables from the internet.
* Office applications restricted from spawning child processes (e.g., PowerShell).
Elevation Control: Time-bound, auditable elevation requests instead of permanent local admin rights.
3.2 Endpoint Detection and Response (Sophos MDR / Defender for Endpoint)
Tamper Protection: Enabled.
Scan Exclusions: Strictly managed centrally; no wildcards for user directories (e.g., C:\Users\*\Downloads).
Web Control: Malicious and unrated sites blocked.
Device Control: Removable media (USB) blocked or set to read-only for standard users.
Internal documentation, Standard Operating Procedures (SOPs), and client asset tracking.
10.1 Confluence
Access Control: Integrated with Entra ID for Single Sign-On (SSO) and Conditional Access (MFA enforced).
Space Structure:
* Segregated spaces for Internal SOPs, Client Documentation, and Compliance Frameworks.
* Strict Permission Schemes applied per space (e.g., restricted access for sensitive client credentials or security configurations).
Versioning & Auditing: Page history and version control enabled for all SOPs and technical frameworks to track changes.
Review Cadence: Core compliance and baseline documents (like this framework) set with automated review reminders every 6-12 months.
External Sharing: Anonymous access disabled globally. External sharing strictly controlled and limited to specific, short-lived client collaboration spaces.
Document Version: 1.0Last Updated: March 2026
PART 2
Technical Baselines
M365 & Entra ID Security Baseline
Document ID: NET-BL-M365-001
Version: 1.0
Effective Date: 2026-03-26
Next Review: 2026-09-26
Owner: Netier — GRC / Security Operations
Classification: Internal
1. Overview
This document defines the strict configuration standards for Microsoft 365 and Entra ID environments managed by Netier. It aligns with the ASD ISM, Essential Eight (E8) ML3, and CIS Controls.
2. Entra ID (Azure AD) Configuration
2.1 Authentication & MFA (E8 ML3)
ISM Controls:ISM-1173, ISM-0974, ISM-1401, ISM-1872, ISM-1682, ISM-1919
Legacy Authentication: Blocked globally via Conditional Access. No exceptions.
MFA Enforcement: Phishing-resistant MFA (FIDO2 security keys, Windows Hello for Business) is enforced for all users.
Self-Service Password Reset (SSPR): Enabled, requiring two authentication methods.
2.2 Conditional Access (CA) Policies
ISM Controls:ISM-1546, ISM-1504, ISM-1680, ISM-0428, ISM-1403
The following CA policies are mandatory:
Block Non-AU Logins: Block all sign-ins originating outside of Australia. (Exceptions require PIM approval and specific IP whitelisting).
Require Compliant Device: Access to corporate data (SharePoint, Exchange, Teams) requires the device to be marked as "Compliant" in Intune.
Require MFA for All Users: Enforce MFA for every sign-in attempt not covered by device compliance/SSO.
Sign-in Risk Policy: Block access if sign-in risk is High. Require MFA/Password change if risk is Medium.
User Risk Policy: Require secure password change if user risk is High.
2.3 Privileged Identity Management (PIM)
ISM Controls:ISM-1380, ISM-1173, ISM-1833, ISM-1620, ISM-1939
Standing Access: No standing access for Global Administrator, Exchange Administrator, or SharePoint Administrator roles.
JIT Access: All high-privilege roles require Just-In-Time (JIT) activation via PIM.
Approval Workflow: PIM activation requires MFA, ticketing integration (justification), and peer approval for Global Admin.
Identity Separation: Admin identities must be separate from daily productivity accounts (email/Teams). Global Admins must not use the same account for standard user activities and privileged operations.
2.4 Break Glass (Emergency Access) Accounts
ISM Controls:ISM-1685, ISM-1795, ISM-1954
Requirement: Two Break Glass accounts must exist in every managed Entra ID tenant.
Authentication: FIDO2 security keys stored in separate physical safes (one on-site, one off-site).
CA Exclusion: Excluded from all Conditional Access policies to prevent lockout during Microsoft MFA outages.
Monitoring: Sign-in events on Break Glass accounts trigger immediate alerts to Netier SOC.
3. Microsoft Intune Configuration
ISM Controls:ISM-1406, ISM-1914, ISM-1409, ISM-1745
Device Compliance:
* BitLocker encryption mandatory.
* Antivirus/EDR active and up to date.
* OS version within N-1 of current release.
* Device is active (check-in within last 30 days).
Configuration Profiles:
* Deploy CIS/ASD ISM hardened Windows 11 baselines.
* Disable LLMNR and NetBIOS.
* Disable SMBv1.
* Configure LAPS for local administrator management.
3.1 Application Control (E8 ML3)
ISM Controls:ISM-0843, ISM-1490, ISM-1657, ISM-1544, ISM-1488
Enforcement: Application Control (AppLocker/WDAC/ThreatLocker) enforced on all Intune-managed endpoints, restricting execution to approved publishers, paths, and file hashes.
Macros: Microsoft Office macros from the internet blocked via Intune policy. Trusted locations and digital signatures required for approved macros.
4. Microsoft Defender for Office 365
ISM Controls:ISM-1234, ISM-1502, ISM-1601
Safe Links: Enabled for all users, including Microsoft Teams.
Safe Attachments: Enabled with "Block" or "Dynamic Delivery".
Anti-Phishing: Set to "Strict" mode. Impersonation protection enabled for executive staff and key domains.
Anti-Spam: Outbound spam notifications routed to Netier SOC.
Evidence gathering for these controls will be automated via Netier Compliance Engine API integrations (planned — external ISM scanner operational; full evidence automation in development).
Endpoint & Server Security Baseline
Document ID:NET-BL-EP-001
Version: 1.0
Effective Date: 2026-03-26
Next Review: 2026-09-26
Owner: Netier — GRC / Security Operations
Classification: Internal
1. Overview
This document dictates the security controls for all Windows Server, Active Directory, and endpoint environments managed by Netier, directly mapping to Essential Eight (E8) ML3, ASD ISM, and ISO 27001.
2. Active Directory (On-Premises / Hybrid)
ISM Controls:ISM-1926, ISM-1827, ISM-1620, ISM-1685, ISM-0383
Domain Controllers: Dedicated Server Core installations where possible. No non-essential software.
LAPS (Local Administrator Password Solution): Deployed globally. Local admin passwords rotated every 14 days or immediately after use.
Inactivity Pruning: Automated scripts disable computer and user accounts inactive for >45 days, and delete after >90 days.
3. Application Control (E8 ML3)
ISM Controls:ISM-0843, ISM-1490, ISM-1656, ISM-1657, ISM-1544
Enforcement: AppLocker or Windows Defender Application Control (WDAC) is enforced on all endpoints and servers.
Ruleset: Whitelist approach based on trusted publishers (code-signing certificates), specific paths (e.g., C:\Program Files), and specific file hashes.
Macros: Microsoft Office macros originating from the internet are blocked via GPO/Intune. Macros require trusted locations or digital signatures.
ISM Controls:ISM-1143, ISM-0298, ISM-1696, ISM-1877, ISM-1694
OS Patching:
* Critical/High: Deployed within 48 hours of release.
* Standard: Deployed within 14 days.
Third-Party Patching: Managed via NinjaOne for core applications (browsers, PDF readers, zoom, etc.) mirroring OS SLA.
Servers: Automated maintenance windows established with pre/post-patching reboot checks.
5. Endpoint Detection & Response (EDR)
ISM Controls:ISM-1341, ISM-1034, ISM-1417, ISM-1601, ISM-0582
Deployment: Advanced EDR (e.g., Defender for Endpoint P2, CrowdStrike, SentinelOne) deployed to 100% of assets.
Configuration:
* Tamper protection enabled.
* Cloud-delivered protection enabled.
* Automated investigation and remediation enabled (Full/Active mode).
Isolation: SOC/EDR has automated capabilities to network-isolate compromised hosts.
Attack Surface Reduction (ASR): ASR rules deployed in Block Mode via Intune:
* Block executable files from running unless they meet prevalence, age, or trusted list criteria.
* Block credential stealing from the Windows local security authority subsystem (LSASS).
* Block Office applications from creating executable content.
* Block untrusted and unsigned processes that run from USB.
6. Protocol & Authentication Hardening
ISM Controls:ISM-1055, ISM-1603, ISM-1962, ISM-1686, ISM-1861
SMB Signing: Enforced on all Domain Controllers and file servers. SMBv1 disabled globally.
NTLMv1: Disabled across all managed domains. NTLMv2 restricted to authenticated sessions only where Kerberos is unavailable.
Firmware & Driver Updates: OEM firmware and driver updates deployed via NinjaOne or vendor utilities (Dell Command Update, HP CMSL) within 30 days of release. Critical firmware CVEs patched within 14 days.
Evidence gathering for these controls will be automated via Netier Compliance Engine API integrations with NinjaOne and ThreatLocker (planned — external ISM scanner operational; full evidence automation in development).
Network Perimeter & Infrastructure Baseline
Document ID:NET-BL-NET-001
Version: 1.0
Effective Date: 2026-03-26
Next Review: 2026-09-26
Owner: Netier — GRC / Security Operations
Classification: Internal
1. Overview
This standard details the physical and virtual network perimeter security configurations for Netier managed clients, aligning with NIST CSF, ASD ISM, and PCIDSS.
2. Firewall & Gateway Configuration
ISM Controls:ISM-1528, ISM-0631, ISM-1192, ISM-1427, ISM-1028
Default Posture: Default Deny for both inbound and outbound traffic. Explicit allow rules only.
Next-Gen Features: Intrusion Prevention System (IPS) and Deep Packet Inspection (DPI/SSL Decryption) enabled on core traffic paths.
Geo-IP Blocking: Inbound traffic restricted to Australia (AU) unless a documented business case exists. Known malicious exit nodes (Tor, generic VPNs) blocked.
Management Interfaces: Blocked from WAN. Accessible only via dedicated management VLAN or ZTNA/VPN from Netier infrastructure.
3. Network Segmentation (Micro-segmentation)
ISM Controls:ISM-1181, ISM-1577, ISM-1182, ISM-0385
Networks must be segregated into distinct VLANs with strict inter-VLAN routing controls:
Guest/IoT VLAN: Completely isolated from corporate networks. IoT devices have outbound internet access explicitly whitelisted to required vendor endpoints only (not general internet). Guest VLAN has client isolation enabled.
4. Network Access Control (NAC)
ISM Controls:ISM-0520, ISM-1321, ISM-1332, ISM-0534
Wired & Wireless: 802.1x authentication is enforced on all corporate physical ports and Wi-Fi networks.
Authentication: Certificate-based authentication (EAP-TLS) preferred. MAC Auth Bypass (MAB) strictly limited to non-802.1x capable devices (e.g., printers) on restricted VLANs.
5. Network Device Management
ISM Controls:ISM-1304, ISM-1800, ISM-1963, ISM-0518, ISM-1782
Configuration Backups: Automated configuration backups for all perimeter devices (firewalls, routers, switches) via Unimus, Auvik, or oxidized. Daily backups with 90-day retention.
Firmware Patching: Critical CVEs on perimeter devices must be patched within 14 days of vendor advisory. Non-critical firmware updates within 30 days.
DNS Security/Filtering: Secure DNS resolver (Cloudflare Gateway, Cisco Umbrella, or NextDNS) mandated at the DHCP scope level to block malicious domains before traffic reaches the firewall.
6. Remote Access
ISM Controls:ISM-0619, ISM-0705, ISM-1781, ISM-0469
Zero Trust Network Access (ZTNA): Transitioning away from full-tunnel VPNs. Access provided on a per-application basis utilizing Entra ID Application Proxy or dedicated ZTNA solutions.
VPN Controls (Legacy): Where traditional VPNs exist, Entra ID SSO with MFA is mandatory. Split tunneling is disabled for high-security clients (DISP/SOCI).
Evidence gathering for these controls will be automated via Netier Compliance Engine API integrations (planned — external ISM scanner operational; full evidence automation in development).
Email Security, Web Posture & Deliverability Baseline
Document ID:NET-BL-EMAIL-001
Version: 1.0
Effective Date: 2026-03-26
Next Review: 2026-09-26
Owner: Netier — GRC / Security Operations
Classification: Internal
1. Overview
This baseline covers external-facing assets, focusing on email authentication, deliverability, and web application security. It integrates controls across Cloudflare, Valimail, PowerDMARC, Sendmarc, Postmaster, and performance metrics (Speedtest/PageSpeed), aligning with ISM, CIS, and Privacy Act requirements.
2. Email Authentication & Deliverability
ISM Controls:ISM-0264, ISM-0569, ISM-0572, ISM-1589
Netier mandates a strict email authentication framework to prevent spoofing and ensure high deliverability rates.
2.1 Sender Policy Framework (SPF)
ISM Controls:ISM-0574, ISM-1183, ISM-1151
Configuration: Explicitly define all authorized sending IPs and services.
Limit: Strict adherence to the 10 DNS lookup limit. When limits are hit, use Valimail/PowerDMARC SPF Flattening or SPF Macro features rather than manual IP flattening (which leads to maintenance drift).
Policy: Must end with ~all (soft fail during tuning) transitioning to -all (hard fail) in production.
2.2 DomainKeys Identified Mail (DKIM)
ISM Controls:ISM-0861, ISM-1026
Configuration: 2048-bit keys minimum. DKIM keys must be rotated annually.
Alignment: 100% of outbound mail streams must be DKIM signed.
2.3 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
ISM Controls:ISM-1540, ISM-1799
Enforcement: The final state for all managed domains is p=reject.
Management Tools: Valimail, PowerDMARC, or Sendmarc must be utilized to aggregate RUA/RUF reports and maintain SPF/DKIM alignment dynamically.
Monitoring: Continuous monitoring via Postmaster tools for domain reputation and spam rate metrics.
2.4 Inbound Email Protection (Microsoft Defender for Office 365)
ISM Controls:ISM-1234, ISM-1502, ISM-0572, ISM-1589
Executable Blocking: Drop all inbound attachments with executable extensions (.exe, .bat, .ps1, .vbs, .js, .wsf).
Anti-Phishing: Strict mode with impersonation protection for executive staff and key domains (cross-reference: M365 baseline Section 4).
Zero-hour Auto Purge (ZAP): Enabled for both malware and phishing messages retroactively removed from mailboxes post-delivery.
High-Confidence Phishing: Quarantine action with no end-user release capability.
3. Web Posture & Security (Cloudflare)
ISM Controls:ISM-0963, ISM-0958
All public-facing web applications and sites must be protected via Cloudflare (or equivalent Enterprise WAF).
3.1 Web Application Firewall (WAF)
ISM Controls:ISM-1862, ISM-0963, ISM-1431
Mode: Strict block mode for known malicious payloads (SQLi, XSS, LFI).
Bot Management: Super Bot Fight Mode (or equivalent) enabled to challenge/block automated scrapers and malicious bots.
HSTS: HTTP Strict Transport Security (HSTS) enabled with includeSubDomains and preload.
3.3 Performance Metrics (OLAs)
ISM Controls:ISM-1581, ISM-1438
Performance is considered a security/availability metric.
PageSpeed: Cloudflare caching, image optimization, and minification enabled to meet baseline Core Web Vitals targets.
Speedtest/Latency: Automated monitoring to ensure global latency and load times remain within defined Operational Level Agreements (OLAs).
Evidence gathering for these controls will be automated via Netier Compliance Engine API integrations (planned — external ISM scanner operational; full evidence automation in development).
Operational Policies & Governing Plans
Document ID:NET-BL-OPS-001
Version: 1.0
Effective Date: 2026-03-26
Next Review: 2026-09-26
Owner: Netier — GRC / Security Operations
Classification: Internal
1. Overview
This document outlines the required structure and mandates for Netier's core operational policies. These policies govern the technical baselines and provide the administrative controls required for ISO 27001, SOCI Act, DISP, and SOC II.
2. Incident Response Plan (IRP)
ISM Controls:ISM-0576, ISM-1784, ISM-0125, ISM-0123, ISM-0140
Objective: Define the process for identifying, investigating, responding to, and recovering from security incidents.
* ACSC (ASD): Critical cyber security incidents affecting national infrastructure (SOCI) or defence (DISP) must be reported to the ACSC within 12 hours of becoming aware (s30CD). Other significant incidents within 72 hours (s30CE).
* OAIC: Notifiable Data Breaches (NDB) under the Privacy Act must be reported within 72 hours of confirmation.
Post-Incident Review: A Post-Incident Report (PIR) must be completed within 14 days of incident closure, with resulting remediation tasks tracked in the risk register.
Testing: Tabletop exercises conducted at least annually.
3. Business Continuity Plan (BCP)
ISM Controls:ISM-1437, ISM-1579, ISM-1580, ISM-1431
Objective: Ensure Netier and its clients can maintain critical operations during a major disruption.
Key Metrics:
* MTPD: Maximum Tolerable Period of Disruption (defined per service tier).
* RTO/RPO: Recovery Time Objective and Recovery Point Objective.
Scope: Covers physical site loss, critical system failure (e.g., NinjaOne outage), and loss of key personnel.
4. Disaster Recovery Plan (DRP)
ISM Controls:ISM-1547, ISM-1548, ISM-1511, ISM-1515, ISM-1708
Objective: The technical steps to restore IT infrastructure and data following a disaster.
Backup Architecture (E8 ML3):
* Immutable, offline, or offsite backups are mandatory.
* Backups must be protected from domain/tenant compromise (separate authentication plane).
* Backups must be encrypted at rest (AES-256) and in transit, with encryption keys managed securely and separately from the primary infrastructure.
Testing Frequency:
* Enterprise Tier: Quarterly full restoration tests.
* Professional Tier: Bi-annual restoration tests.
* Essential Tier: Annual restoration tests.
5. Supply Chain Management (SCM)
ISM Controls:ISM-1631, ISM-1452, ISM-1568, ISM-1569, ISM-0072
Objective: Manage risks introduced by third-party vendors and SaaS providers.
Vendor Assessment: Mandatory security questionnaire and review of vendor SOC II Type 2 / ISO 27001 certifications prior to onboarding.
Data Sovereignty: Explicit tracking of where data is hosted. High-risk data must remain in Australia. US-based SaaS tools require specific risk acceptance and mitigating controls.
Shared Responsibility Matrix: A documented matrix explicitly defining security responsibilities between Netier, the Vendor, and the Client.
Evidence gathering for these plans (e.g., backup logs, test results, vendor approvals) will be automated via Netier Compliance Engine API integrations (planned — external ISM scanner operational; full evidence automation in development).
PART 3
Standard Operating Procedures
SOP: Infrastructure & Compute Hardening
Document ID:NET-SOP-INFRA-001 Version: 1.0 Effective Date: 2026-03-26 Next Review: 2026-09-26 Owner: Netier — Security & Cloud Engineering Classification: Internal TCF Section: 1.0 Review Cycle: Quarterly or after vendor portal/product changes
Verify vCenter web client is only accessible from management VLAN or authorized VPN subnets.
Firewall Rule Example (FortiGate CLI):
config firewall policy
edit 100
set srcintf "VLAN_MGMT"
set dstintf "VLAN_HYPERVISOR"
set srcaddr "Mgmt-Admins"
set dstaddr "vCenter-Server" "ESXi-Hosts"
set action accept
set service "HTTPS"
set logtraffic all
next
end
2. AD-Integrated MFA for vCenter
In vCenter > Administration > Single Sign-On > Configuration > Identity Sources, add the AD domain as an identity source (Integrated Windows Authentication or LDAPS).
Assign AD security groups to vCenter roles: vCenter > Administration > Access Control > Global Permissions > Add the vSphere-Admins AD group with Administrator role.
Integrate MFA via Duo/RSA:
- Install Duo Authentication Proxy on a management server.
- Configure vCenter to use the Duo RADIUS proxy as secondary authentication.
- Test MFA prompt on vCenter login.
3. AD-Integrated MFA for Hyper-V Manager
Hyper-V Manager natively uses Windows authentication. Enforce MFA via Entra ID Conditional Access:
- Navigate to Entra admin center > Protection > Conditional Access > Policies > New policy.
- Name: Require MFA for Hyper-V Administration.
- Assignments > Users: Select the Hyper-V Admins group.
- Assignments > Target resources > Cloud apps: Windows Remote Management (WinRM) or apply to All cloud apps scoped to admin users.
- Conditions > Client apps: Browser, Mobile apps and desktop clients.
- Grant > Require multifactor authentication.
Alternatively, use Windows Hello for Business or Smart Card logon for RDP sessions to Hyper-V hosts.
- Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment
- Deny log on through Remote Desktop Services: Add Domain Users group (or the broadest standard user group).
- Allow log on through Remote Desktop Services: Add only Remote Desktop Admins (a dedicated AD security group for authorized RDP users) and Domain Admins.
- Notify on: Failure and Warning (not Success, to reduce noise).
Verification Checks
☐ Backup jobs run daily and complete successfully (check Veeam console)
☐ Immutable storage is active: backup files have immutable flag and cannot be deleted before retention expires
☐ Application-aware processing (VSS) completes without errors for SQL/Exchange/AD servers
☐ Offsite replication (Veeam Cloud Connect) is current within the last 24 hours
☐ Backup monitoring alerts are firing correctly (test by stopping a backup job and verifying ticket creation)
☐ Restore test completed within the last quarter (document date and result)
☐ SureBackup (Veeam) shows VMs boot successfully from backup
Rollback
If a backup job causes performance issues, adjust the schedule to a different maintenance window.
If immutability is blocking legitimate deletions (e.g., storage full), you must wait for the immutability period to expire. Plan storage capacity accordingly.
To temporarily disable a backup job: right-click the job in Veeam > Disable. Document the reason and re-enable within 24 hours.
Master Verification Checklist
Windows Server Hardening
☐ CIS Level 1 baseline GPO applied and verified via gpresult
☐ Credential Guard running (VBS status = 2, Security Services includes 1)
☐ Application-aware processing working for SQL/Exchange/AD
☐ Offsite replication current (within 24 hours)
☐ Monitoring alerts configured and tested
☐ Quarterly restore test documented
Document History
Date
Author
Change
2026-03-26
Netier Security Engineering
Initial creation
Standard Operating Procedures: Identity, Conditional Access & Cloud Workspace Security
Document ID:NET-SOP-IDM-001 Version: 1.1 Effective Date: 2026-03-26 Next Review: 2026-09-26 Owner: Netier — Security & Cloud Engineering Classification: Internal TCF Section: 2.0 Review Cycle: Quarterly or after any Microsoft portal change Applies to: All Netier-managed Microsoft 365 / Entra ID tenants
Break glass accounts must be created BEFORE any Conditional Access policies are deployed. These accounts provide emergency access if CA policies, MFA, or PIM malfunction.
Prerequisites
Global Administrator access to the tenant
Two FIDO2 security keys (e.g., YubiKey 5 NFC)
Two separate physical safes — one on-site, one off-site
Netier SOC email distribution list or alert channel configured
A custom domain verified on the tenant (Use the tenant's primary custom domain for break glass accounts for consistency with monitoring and alerting. Note: some organisations prefer .onmicrosoft.com to survive custom domain deprovisioning — document the decision and rationale either way)
Step-by-Step Instructions
Navigate to Entra Admin Center > Identity > Users > All users > + New user > Create new user.
Create the first account:
- Username: BreakGlass1@
- Display Name: Break Glass 1 — DO NOT DELETE
- No group memberships at creation
- Assign the Global Administrator role directly (not via PIM)
Repeat for BreakGlass2@.
For each account, set a long random password (20+ characters, generated, stored only in sealed envelopes in the physical safes).
Register a FIDO2 security key for each account:
- Sign in as the break glass account at https://mysignins.microsoft.com
- Navigate to Security info > + Add sign-in method > Security key
- Follow the on-screen prompts to register the FIDO2 key
- Store each key in its designated safe (BG1 = on-site, BG2 = off-site)
Disable phone-based MFA methods for both accounts — FIDO2 only.
Configure sign-in alerts:
- Navigate to Entra Admin Center > Identity > Monitoring & health > Diagnostic settings > + Add diagnostic setting.
☐ Both accounts can sign in successfully using FIDO2 keys
☐ Both accounts hold the Global Administrator role (directly assigned, not via PIM)
☐ Sign-in alert fires within 5 minutes of a test login
☐ Netier SOC confirms receipt of the test alert
☐ FIDO2 keys are physically secured in separate safes
☐ Accounts are excluded from ALL Conditional Access policies (verify in each policy)
☐ Passwords and key locations are documented in the sealed register
Rollback
If a break glass account is compromised:
Immediately disable the compromised account in Entra Admin Center.
Use the other break glass account to regain access.
Revoke all sessions: Revoke-MgUserSignInSession -UserId .
Create a replacement account following this SOP.
Register a new FIDO2 key and store in the same safe.
Investigate the compromise via Entra sign-in logs and Defender for Cloud Apps.
Conditional Access Policies
IMPORTANT: Before creating any Conditional Access policy, ensure break glass accounts exist and will be excluded from every policy. Deploy policies in Report-only mode first, monitor for 7 days via the CA Insights workbook, then switch to On after confirming no legitimate users are blocked.
Exclusion Group Setup
Before creating individual policies, create a single exclusion group for break glass accounts:
Navigate to Entra Admin Center > Identity > Groups > All groups > + New group.
Group type: Security
Group name: SG-CA-BreakGlass-Exclusions
Members: Add BreakGlass1 and BreakGlass2
Use this group in the Exclude > Users and groups section of every CA policy below.
Block Legacy Authentication
Legacy authentication protocols (POP3, IMAP, SMTP AUTH, Exchange ActiveSync basic auth) bypass MFA and are the most common vector for password spray attacks. This policy blocks them globally with no exceptions.
Prerequisites
Confirm no business-critical applications depend on legacy auth (check sign-in logs filtered to "Legacy Authentication Clients" for the past 30 days)
Break glass exclusion group created
Step-by-Step Instructions
Navigate to Entra Admin Center > Protection > Conditional Access > Policies > + New policy.
Name: BLOCK — Legacy Authentication
Assignments:
- Users: Include > All users
- Users: Exclude > Select users and groups > SG-CA-BreakGlass-Exclusions
- Target resources: Include > All cloud apps
Conditions:
- Client apps > Configure: Yes
- Select: Exchange ActiveSync clients and Other clients
- Deselect: Browser, Mobile apps and desktop clients
Access controls > Grant: Select Block access
Enable policy: Report-only (switch to On after 7-day monitoring)
☐ Policy appears in the CA policy list with correct state (Report-only, then On)
☐ Sign-in logs show legacy auth attempts being blocked/reported
☐ No legitimate business applications are affected (check CA Insights workbook)
☐ Break glass accounts are excluded
☐ Test: attempt an IMAP connection with valid credentials and confirm it is blocked
Rollback
Navigate to the policy and set Enable policy to Off.
Investigate which legacy auth flows were impacted.
If a specific app genuinely requires legacy auth (rare), raise it as a risk acceptance with the client and document it.
Block Non-AU Logins (Geo-Fencing)
This policy blocks all sign-ins originating from outside Australia. Exceptions for travel or offshore workers require PIM approval and an IP whitelist entry.
Prerequisites
Break glass exclusion group created
Named location for Australia created (or confirm it exists)
Step-by-Step Instructions
Create Named Location (Australia):
- Navigate to Entra Admin Center > Protection > Conditional Access > Named locations > + Countries location.
- Name: Allowed Countries — Australia
- Select: Australia
- Determine location by: IP address (recommended for accuracy)
- Click Create
Create the Policy:
- Navigate to Entra Admin Center > Protection > Conditional Access > Policies > + New policy.
- Name: BLOCK — Non-AU Sign-ins
- Assignments:
- Users: Include > All users
- Users: Exclude > SG-CA-BreakGlass-Exclusions
- Target resources: Include > All cloud apps
- Conditions:
- Locations > Configure: Yes
- Include: Any location
- Exclude: Selected locations > Allowed Countries — Australia
- Access controls > Grant: Select Block access
- Enable policy: Report-only (switch to On after 7-day monitoring)
- Click Create
Handling Travel Exceptions:
- User raises a ticket requesting temporary access from a specific country
- A PIM-eligible admin activates their role (see PIM section)
- Create a new named location for the traveller's IP range or country
- Create a time-limited exclusion (or use a dedicated security group for travellers)
- Set a calendar reminder to remove the exception on the return date
☐ Named location for Australia exists and contains only AU
☐ Policy is active and scoped to all users (minus break glass)
☐ Test from a non-AU VPN/IP — sign-in is blocked
☐ Test from an AU IP — sign-in succeeds
☐ CA Insights workbook shows no false positives after 7 days
☐ Travel exception process is documented and communicated to the client
Rollback
Set the policy to Off in the Conditional Access blade.
If the named location is incorrect, edit it under Named locations.
For a user locked out while travelling, add their country or IP to the exclude list immediately, then investigate.
Require Compliant Device
Access to SharePoint Online, Exchange Online, and Microsoft Teams requires the device to be enrolled in Intune and marked as Compliant. This prevents data access from unmanaged personal devices.
☐ Policy targets Exchange Online, SharePoint Online, and Teams
☐ A compliant device can access all three workloads without issue
☐ A non-compliant (or unenrolled) device is blocked with a clear remediation message
☐ Break glass accounts are excluded
☐ Guest/external users are handled appropriately (exclude or provide separate policy)
☐ Mobile devices enrolled via Company Portal are marked compliant
Rollback
Set the policy to Off.
If users are locked out due to compliance evaluation delays, temporarily set to Report-only while Intune catches up.
Check Intune compliance status: Intune Admin Center > Devices > All devices > [device] > Device compliance.
Require MFA for All Users
All users must authenticate with phishing-resistant MFA (FIDO2 security keys or Windows Hello for Business). This replaces legacy MFA per-user settings and Security Defaults.
Prerequisites
Disable Security Defaults if enabled: Entra Admin Center > Identity > Overview > Properties > Manage Security defaults > Disabled
Disable legacy per-user MFA: Entra Admin Center > Identity > Users > All users > Per-user MFA (set all users to Disabled; CA policies take over)
FIDO2 and/or Windows Hello for Business enabled as authentication methods
Break glass exclusion group created
Step-by-Step Instructions
Enable phishing-resistant authentication methods:
- Navigate to Entra Admin Center > Protection > Authentication methods > Policies.
- FIDO2 security key: Enable > Target: All users (or a pilot group initially)
- Windows Hello for Business: Enable > Target: All users
- Microsoft Authenticator: Enable (as fallback during transition, plan to disable push/OTP once FIDO2/WHfB adoption is complete)
Create the Conditional Access policy:
- Navigate to Entra Admin Center > Protection > Conditional Access > Policies > + New policy.
- Name: REQUIRE — MFA for All Users (Phishing-Resistant)
- Assignments:
- Users: Include > All users
- Users: Exclude > SG-CA-BreakGlass-Exclusions
- Target resources: Include > All cloud apps
- Conditions: Leave all at Not configured (applies to all conditions)
- Access controls > Grant:
- Select Require authentication strength
- Choose Phishing-resistant MFA (built-in strength that includes FIDO2 and Windows Hello)
- Enable policy: Report-only (switch to On after 7-day monitoring)
- Click Create
Register users for FIDO2/WHfB:
- Direct users to https://mysignins.microsoft.com to register their security keys
- For Windows Hello, ensure devices are joined or registered to Entra ID and WHfB policy is deployed via Intune
PowerShell Alternative:
$policyParams = @{
DisplayName = "REQUIRE - MFA for All Users (Phishing-Resistant)"
State = "enabledForReportingButNotEnforced"
Conditions = @{
Users = @{
IncludeUsers = @("All")
ExcludeGroups = @("<BreakGlass-Group-Id>")
}
Applications = @{
IncludeApplications = @("All")
}
}
GrantControls = @{
Operator = "OR"
AuthenticationStrength = @{
Id = "00000000-0000-0000-0000-000000000004" # Phishing-resistant MFA
☐ Users are prompted for FIDO2/WHfB and cannot fall back to SMS/phone call
☐ Break glass accounts are excluded
☐ Service accounts/app registrations that cannot perform MFA are handled per the procedure below
Handling Service Accounts and App Registrations
Service accounts, app registrations, and headless integrations cannot perform interactive MFA. Each must be handled explicitly — never silently excluded.
Step 1 — Identify all non-interactive accounts:
App registrations: Entra Admin Center > Identity > Applications > App registrations > All applications
Service principal sign-ins: Entra Admin Center > Identity > Monitoring & health > Sign-in logs > Filter: Sign-in type = "Service principal"
Known service accounts: Backup agents, SMTP relay, LOB integrations, SCIM provisioning, monitoring agents
Assign system/user-assigned managed identity. Managed identities are excluded from CA by default. No credentials to manage.
Workload Identity CA policy
App registrations authenticating via client credentials
Create separate CA policy targeting Workload identities (Preview). Apply controls: restrict to Netier IPs only, block legacy auth protocols.
Service account exclusion (last resort)
Legacy integrations that cannot use managed identity or workload identity
Add to dedicated security group SG-CA-ServiceAccounts. Exclude from MFA policy ONLY. Compensating controls required: restrict sign-in to Netier IPs only (via named location in a separate CA policy), disable interactive logon, monitor via sign-in alerts.
Step 3 — Document every exclusion:
Maintain a Service Account Register (spreadsheet or CW Configuration) with:
Account name / App registration name
Purpose and owner
Exclusion justification
Compensating controls applied
Review date (minimum every 6 months)
Audit requirement: ISO 27001 A.5.18 and ISM-1833 require documented justification for every access exception. An undocumented exclusion is a nonconformity.
Phased Deployment (Critical — Prevents User Lockout)
Do NOT enforce phishing-resistant MFA immediately. Users need time to register FIDO2 keys or Windows Hello. Enforcing before registration is complete will lock out all users without phishing-resistant credentials.
Phase A — Transitional (Weeks 1-4):
Deploy the CA policy above BUT change the Grant control to standard Require multifactor authentication (not phishing-resistant strength). This accepts Authenticator app, SMS, voice + FIDO2/WHfB.
Begin FIDO2 key distribution and user registration via https://mysignins.microsoft.com.
Target: >95% of users registered with FIDO2 or Windows Hello before Phase B.
Phase B — Hardened (Week 5+):
Once >95% adoption confirmed, update the CA policy Grant control:
- Change from Require multifactor authentication to Require authentication strength > Phishing-resistant MFA.
Set policy to Report-only for 7 days — monitor for any users blocked due to missing FIDO2/WHfB registration.
After 7 days with no unexpected blocks, switch to On (enforced).
Disable Microsoft Authenticator push/OTP as authentication methods (optional, for maximum security).
Handling the remaining <5%:
Users who cannot register FIDO2 (e.g., shared mailboxes, kiosk accounts): add to a dedicated exclusion group with compensating controls (IP restriction, compliant device requirement).
Document each exclusion in the Service Account Register.
Rollback
Set the policy to Off or Report-only.
If users cannot register FIDO2 keys, revert grant control to standard Require multifactor authentication (allows Authenticator app) while distributing keys.
Never re-enable Security Defaults — it conflicts with CA policies.
Sign-in Risk Policy
Uses Entra ID Protection to evaluate sign-in risk in real time. High-risk sign-ins are blocked. Medium-risk sign-ins require MFA re-authentication.
Prerequisites
Entra ID P2 (or Microsoft 365 E5) licences assigned to all users
MFA registered for all users (see previous policy)
Break glass exclusion group created
Step-by-Step Instructions
Navigate to Entra Admin Center > Protection > Conditional Access > Policies > + New policy.
Name: RISK — Block High / MFA Medium Sign-in Risk
Assignments:
- Users: Include > All users
- Users: Exclude > SG-CA-BreakGlass-Exclusions
- Target resources: Include > All cloud apps
Conditions:
- Sign-in risk > Configure: Yes
- Risk level: Select High
Access controls > Grant: Select Block access
Enable policy: Report-only
Click Create.
Create a second policy for medium risk:
- Navigate to Entra Admin Center > Protection > Conditional Access > Policies > + New policy.
- Name: RISK — MFA for Medium Sign-in Risk
- Assignments: Same as above (All users, exclude break glass)
☐ Risk detections are populating: Entra Admin Center > Protection > Identity Protection > Risk detections
☐ Break glass accounts are excluded from both policies
☐ Test with a simulated risky sign-in (e.g., anonymous proxy) if safe to do so in a test tenant
Rollback
Set either policy to Off.
If legitimate users are being flagged as high risk, investigate the detection in Identity Protection and dismiss false positives: Protection > Identity Protection > Risky sign-ins > Confirm safe.
Do not lower risk thresholds — investigate root causes instead.
User Risk Policy
Requires users flagged as high risk (leaked credentials, impossible travel patterns) to perform a secure password change.
Prerequisites
Entra ID P2 licences assigned to all users
Self-Service Password Reset (SSPR) enabled for all users
MFA registered for all users
Break glass exclusion group created
Step-by-Step Instructions
Navigate to Entra Admin Center > Protection > Conditional Access > Policies > + New policy.
Name: RISK — Require Password Change for High User Risk
- For multiple controls: Require all the selected controls
Session controls:
- Set Sign-in frequency to Every time.
- This forces re-authentication on every sign-in, which triggers the password change requirement for existing sessions (not just new sign-ins). Without this, a compromised user's existing refresh token remains valid.
Enable policy: Report-only (switch to On after 7-day monitoring)
Click Create.
Enable SSPR (if not already):
- Navigate to Entra Admin Center > Protection > Password reset > Properties.
- Self-service password reset enabled: All
- Authentication methods: require at least 2 methods
- Ensure writeback is configured if hybrid (Entra Connect > Password writeback enabled)
PowerShell Alternative:
$userRiskParams = @{
DisplayName = "RISK - Require Password Change for High User Risk"
For users stuck in a password change loop, manually dismiss the risk: Identity Protection > Risky users > [user] > Dismiss user risk.
Investigate whether the risk detection was a true positive before dismissing.
Privileged Identity Management (PIM)
PIM eliminates standing privileged access. Admins must activate their roles on-demand (just-in-time) with MFA, a justification, and (for Global Admin) peer approval.
Prerequisites
Entra ID P2 licences for all administrators
Break glass accounts already hold permanent Global Admin (excluded from PIM)
Separate admin accounts created for each administrator (e.g., adm-thouston@)
Decide approval chain: who approves Global Admin activations
Step-by-Step Instructions
Create Dedicated Admin Accounts
For each administrator, create a separate account with the adm- prefix:
- Navigate to Entra Admin Center > Identity > Users > + New user
- Username: adm-@
- No M365 productivity licences (no Exchange mailbox, no Teams, no OneDrive)
- Assign only Entra ID P2 licence
Instruct administrators to never use admin accounts for email, browsing, or daily work.
Configure PIM Role Settings
Navigate to Entra Admin Center > Identity Governance > Privileged Identity Management > Entra roles.
Click Roles and select Global Administrator.
Click Settings > Edit.
Activation tab:
- Maximum activation duration: 4 hours (adjust per client policy)
- On activation, require: Azure MFA
- Require justification on activation: Yes
- Require ticket information on activation: Yes
- Require approval to activate: Yes
- Select approver(s): Add designated senior engineers or client IT leadership
- Send notifications when members are assigned as eligible: All admins
- Send notifications when members are activated: All admins + designated SOC mailbox
Click Update.
Repeat for Exchange Administrator and SharePoint Administrator with these adjustments:
- Require approval to activate: No (peer approval not required for these roles per baseline)
- All other settings remain the same (MFA, justification, ticketing)
Assign Eligible Roles
Navigate to Entra Admin Center > Identity Governance > Privileged Identity Management > Entra roles > Roles.
Select the role (e.g., Global Administrator).
Click + Add assignments.
Select the admin accounts (e.g., adm-thouston).
Assignment type: Eligible (never Active, unless it is a break glass account).
Set eligibility duration: 12 months.
Click Assign.
Remove Standing Access
Navigate to Entra Admin Center > Identity > Roles & administrators > Global Administrator.
Review the list of Active assignments.
Remove all active assignments EXCEPT the break glass accounts.
Repeat for Exchange Administrator and SharePoint Administrator.
CAUTION: Ensure at least one PIM-eligible admin can activate before removing the last standing Global Admin. Always test with a second admin account first.
PowerShell Alternative (assign eligible role):
☐ No standing (active) Global Admin, Exchange Admin, or SharePoint Admin assignments exist (except break glass)
☐ All administrators have separate adm- accounts for privileged access
☐adm- accounts have no productivity licences (no mailbox, no Teams)
☐ PIM activation for Global Admin requires MFA + justification + ticket + approval
☐ PIM activation for Exchange/SharePoint Admin requires MFA + justification + ticket (no approval)
☐ Maximum activation duration is 4 hours or less
☐ Eligible assignments expire after 12 months
☐ Test: an admin can successfully request, get approved, and activate Global Admin
☐ Activation and assignment notifications are received by the SOC mailbox
☐ Break glass accounts retain permanent active Global Admin (not managed by PIM)
Rollback
If an admin is locked out of PIM activation, use a break glass account to assign a temporary active role.
If PIM is misconfigured and no admin can activate, use break glass to access PIM settings and correct them.
To revert to standing access temporarily: assign the role as Active via PIM with a short expiry while troubleshooting.
Local Access — LAPS
Windows Local Administrator Password Solution (LAPS) ensures every endpoint and server has a unique, automatically rotated local admin password stored securely in Entra ID.
Prerequisites
Devices are Entra ID joined or hybrid joined
Intune-managed (for cloud LAPS) or GPO-managed (for on-prem AD LAPS)
Windows 10 21H2+ or Windows 11 (cloud LAPS built in)
Windows Server 2019+ for servers
Entra ID P1 or higher
Step-by-Step Instructions
Enable LAPS in Entra ID
Navigate to Entra Admin Center > Identity > Devices > All devices > Device settings.
Under Local administrator settings, toggle Enable Microsoft Entra Local Administrator Password Solution (LAPS) to Yes.
Click Save.
Configure LAPS via Intune
Navigate to Intune Admin Center > Endpoint security > Account protection > + Create policy.
Platform: Windows 10 and later
Profile: Local admin password solution (Windows LAPS)
Settings:
- Backup directory: Azure AD only (for cloud-native) or Active Directory (for hybrid)
- Password age (days): 14
- Administrator account name: Leave default (built-in Administrator) or specify a custom local admin account name
- Password complexity: Large letters + small letters + numbers + special characters
Note: Password auto-rotates after post-authentication delay
Verification Checks
☐ LAPS is enabled in Entra device settings
☐ Intune LAPS policy targets all managed Windows devices
☐ Password rotation is set to 14 days
☐ Post-authentication reset is set to 1 hour
☐ LAPS passwords are visible in Entra Admin Center for managed devices
☐ Only authorised roles (Cloud Device Administrator or custom role) can read LAPS passwords
☐ Test: retrieve a password, use it, and confirm it rotates within 1 hour
☐ Servers are also covered (either via Intune or GPO-based LAPS)
Rollback
If LAPS locks out a local admin account, use the stored password from Entra ID.
If the policy is causing issues, set the Intune policy assignment to a smaller group while investigating.
The previous password remains valid until rotation occurs.
Intune Device Compliance Policy
These compliance policies define the minimum security posture required for a device to be marked "Compliant" in Entra ID (which the Conditional Access policy above relies on).
Prerequisites
Intune licences assigned to all users with managed devices
Devices enrolled in Intune
BitLocker recovery keys escrowed to Entra ID
Defender for Endpoint onboarded (or third-party AV/EDR integrated with Intune)
Step-by-Step Instructions
Navigate to Intune Admin Center > Devices > Compliance > + Create policy.
Platform: Windows 10 and later
Name: Netier Baseline — Windows Compliance
Compliance settings:
Device Health:
- Require BitLocker: Require
- Require Secure Boot to be enabled on the device: Require
- Require code integrity: Require
Device Properties:
- Minimum OS version: Set to N-1 (e.g., if current is 10.0.26100, set minimum to 10.0.22631 for Windows 11 23H2 or equivalent)
System Security:
- Require a password to unlock mobile devices: Require
- Encryption of data storage on device: Require
- Firewall: Require
- Antivirus: Require
- Antispyware: Require
- Microsoft Defender Antimalware: Require
- Microsoft Defender Antimalware minimum version: Current or N-1
- Microsoft Defender for Endpoint — Require the device to be at or under the machine risk score: Clear (medium or low recommended)
Microsoft Defender for Endpoint:
- Require the device to be at or under the machine risk score: Medium (blocks high-risk devices)
Actions for noncompliance:
- Mark device noncompliant: Immediately (0 days)
- Send email to end user: 1 day after noncompliance
- Remotely lock the device: 7 days (optional, discuss with client)
- Retire the noncompliant device: 30 days (matches check-in requirement)
Assignments: All users or all devices (depending on tenant structure)
Click Create.
Set compliance policy deadline (device check-in):
- Navigate to Intune Admin Center > Devices > Compliance > Compliance policy settings.
- Mark devices with no compliance policy assigned as: Not compliant
- Compliance status validity period (days): 30
Verification Checks
☐ Compliance policy is assigned to all managed Windows devices
☐ BitLocker is required and keys are escrowed to Entra ID
☐ AV/EDR is required and enforced
☐ OS version check is set to N-1 of the current release
☐ Devices that have not checked in for 30 days are marked non-compliant
☐ Non-compliant devices are blocked from accessing M365 (via the Require Compliant Device CA policy)
☐ Test: deliberately disable BitLocker on a test device and confirm it becomes non-compliant
☐ Noncompliance email notifications are being sent to users
Rollback
If the compliance policy is too aggressive and locks out many users, widen the grace period under Actions for noncompliance (e.g., 3 days instead of immediate).
To exempt a specific device temporarily, add it to an exclusion group and exclude that group from the compliance policy assignment.
Check individual device compliance: Intune Admin Center > Devices > All devices > [device] > Device compliance.
Application Control (Intune)
Application control prevents unauthorised executables and scripts from running. This section covers AppLocker/WDAC via Intune and Office macro restrictions.
Prerequisites
Intune-managed Windows 10/11 Enterprise or Education devices
Existing application inventory (audit mode first to build baseline)
ThreatLocker agent deployed (if using ThreatLocker instead of native WDAC)
Code signing certificates for in-house applications (if applicable)
Step-by-Step Instructions
WDAC via Intune (Recommended for New Deployments)
Create a WDAC base policy on a reference machine:
# On a clean reference machine with all approved apps installed
- Navigate to Intune Admin Center > Endpoint security > Application control > + Create policy.
- Platform: Windows 10 and later
- Profile: Windows Defender Application Control
- Upload the policy binary
- Target: Pilot group first, then expand
Monitor in Audit mode for 30 days:
- Check Event Viewer: Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational
- Review blocked applications and add legitimate ones to the allow list
- Once satisfied, change policy to Enforced mode (remove Option 3)
Office Macro Restrictions
Navigate to Intune Admin Center > Devices > Configuration > + Create > New policy.
Platform: Windows 10 and later
Profile type: Settings catalog
Name: Netier Baseline — Office Macro Restrictions
Add settings by searching for each:
Block macros from the internet (all Office apps):
- Search: "Block macros from running in Office files from the Internet"
- Microsoft Word, Excel, PowerPoint, Access, Visio: Enabled
VBA Macro notification settings:
- Search: "VBA Macro Notification Settings"
- For Word, Excel, PowerPoint: Disable all except digitally signed macros
Trusted Locations:
- Search: "Allow Trusted Locations on the network"
- Set to: Disabled (only local trusted locations)
- Or if network paths are required, define specific UNC paths via:
- Search: "Trusted Location #1" through "Trusted Location #5"
- Set each path explicitly (e.g., \\fileserver\approved-macros\)
Assignments: All Intune-managed Windows devices
Click Create.
ThreatLocker (If Deployed)
If ThreatLocker is the primary application control platform:
Deploy ThreatLocker agent via Intune (Win32 app or LOB app deployment)
Configure policies in ThreatLocker portal:
- Default Deny mode for all unlisted applications
- Ringfencing for permitted applications (restrict app-to-app communication)
- Elevation control for admin-required applications
- Storage control for USB/removable media
Set learning mode for 2 weeks on new deployments, then switch to Secured mode
Verification Checks
☐ WDAC policy deployed in Audit mode and generating logs (or ThreatLocker agent reporting)
☐ After 30-day audit, policy switched to Enforced mode
☐ Office macros from internet-downloaded files are blocked across all Office apps
☐ Only digitally signed macros execute (outside of trusted locations)
☐ Trusted locations are explicitly defined (no broad network shares)
☐ Test: download a macro-enabled file from the internet and confirm macros are blocked
☐ Test: run an unsigned executable and confirm it is blocked (in enforce mode)
☐ ThreatLocker (if applicable) shows all endpoints in Secured mode
Rollback
WDAC: Switch policy back to Audit mode by re-enabling Option 3 and redeploying.
Office Macros: Set VBA Macro Notification to Enabled with notification temporarily.
ThreatLocker: Switch affected machine to Learning mode in the ThreatLocker portal.
Investigate the blocked application and add it to the allow list if legitimate.
Defender for Office 365
Defender for Office 365 protects email and collaboration tools against phishing, malware, and business email compromise.
Prerequisites
Microsoft Defender for Office 365 Plan 1 or Plan 2 licences (included in M365 E5)
Exchange Online mailboxes
Netier SOC distribution list for outbound spam notifications
Step-by-Step Instructions
Safe Links
Navigate to Microsoft Defender portal (security.microsoft.com) > Email & collaboration > Policies & rules > Threat policies > Safe Links.
Click + Create or edit the default policy.
Name: Netier Baseline — Safe Links
Users and domains: Apply to all users in the tenant
URL & click protection settings:
- On: Safe Links checks a list of known, malicious links when users click links in email: Yes
- Apply Safe Links to email messages sent within the organisation: Yes
- Apply real-time URL scanning for suspicious links and links that point to files: Yes
- Wait for URL scanning to complete before delivering the message: Yes
- Do not rewrite URLs, do checks via Safe Links API only: No (rewrite for visibility)
> Note: Microsoft is transitioning to API-only Safe Links checks for modern Outlook clients (desktop and mobile). URL rewriting remains necessary for Outlook on the web (OWA) and legacy clients. Review this setting at next quarterly review to align with Microsoft's deprecation timeline.
- Apply Safe Links to messages sent within Microsoft Teams: Yes
Users and domains: Apply to all users in the tenant
Settings:
- Safe Attachments unknown malware response:Dynamic Delivery (delivers email body immediately, reattaches clean attachment after scan; use Block for higher security tenants where delivery delay is acceptable)
- Quarantine policy: Default (AdminOnlyAccessPolicy or custom)
- Redirect messages with detected attachments: Enable, redirect to Netier SOC mailbox for investigation
- Apply the Safe Attachments detection response if scanning can't complete: Yes (treat as malicious if scan times out)
Click Submit.
Enable Safe Attachments for SharePoint, OneDrive, and Teams:
Monitor the Denied Applications tab for the first 48 hours after switching to Secured Mode. Expect help desk tickets for legitimate applications that were missed during learning.
If Intune-managed, edit the ASR policy and set the specific rule to Audit or Not configured.
Re-enable within 48 hours. Document the exception in ConnectWise Manage.
Application Control Policy Validation (Annual Review)
ISM Controls:ISM-0843, ISM-1490
Prerequisites
ThreatLocker portal access with Organization Admin role
Sophos Central access to review exclusion lists
Defender for Endpoint access to review ASR exclusions
Change management ticket created in ConnectWise Manage for the annual review (type: Scheduled Review)
Step-by-Step Instructions
1. ThreatLocker Annual Ruleset Review
Navigate to ThreatLocker Portal > Policies > Application Control > [Client Org].
Export the full allowlist: Actions > Export Policies (CSV format).
Review each policy entry against the following criteria:
- Is the application still in use? Cross-reference with software inventory from NinjaOne or ConnectWise Automate.
- Is the publisher certificate still valid? Check expiry dates on certificate-based rules.
- Are there hash-only rules that could be upgraded to certificate rules? (reduces maintenance burden)
- Are there overly broad path rules? (e.g., C:\Users\\ -- these should be tightened)
- Are there entries for applications that have been decommissioned? Remove them.
Document findings in a review spreadsheet with columns: Policy Name, Type (cert/path/hash), Status (Keep/Remove/Modify), Justification.
Implement changes and have a second engineer verify.
2. Sophos Exclusion Review
Navigate to Sophos Central > [Client Tenant] > Global Settings > Global Exclusions.
Review each exclusion:
- Is the exclusion still required? Contact the vendor or check KB articles for current requirements.
- Is the exclusion scoped appropriately? Tighten if possible (e.g., change folder exclusion to process exclusion).
- Are there any wildcard exclusions for user directories? Remove immediately unless there is exceptional documented justification with compensating controls.
Check Scanning Exclusions in each endpoint protection policy as well (per-policy exclusions may exist in addition to global ones).
3. Defender ASR Exclusion Review
Navigate to Microsoft Intune admin center > Endpoint security > Attack surface reduction and open each ASR policy.
Review all exclusions in the policy.
Alternatively:
# Review ASR exclusions across all managed devices (via M365 Defender Advanced Hunting)
# DeviceEvents
# | where ActionType == "AsrRuleExclusionApplied"
# | where Timestamp > ago(90d)
# | summarize count() by FileName, FolderPath
# | order by count_ desc
Remove any exclusions that are no longer needed.
Ensure all remaining exclusions have documented justification.
4. Document and Close Review
Update the review spreadsheet with all findings and actions taken.
Store the review document in the client's SharePoint site under IT Security > Annual Reviews.
Update the ConnectWise Manage ticket with the review summary and close.
Set a reminder for the next annual review (12 months from completion date).
Verification Checks
☐ ThreatLocker allowlist exported and reviewed (all entries have valid justification)
☐ Stale or decommissioned application policies removed from ThreatLocker
☐ Sophos global exclusions reviewed (no wildcard user directory exclusions)
☐ Sophos per-policy scanning exclusions reviewed
☐ Defender ASR exclusions reviewed (all have documented justification)
☐ Review findings documented in client SharePoint
☐ ConnectWise Manage review ticket closed with summary
☐ Next annual review date set (12 months)
Rollback
If a removed policy causes application breakage, re-add the policy from the exported CSV backup.
In ThreatLocker, check the Denied Applications view to identify what was blocked and create a targeted allowlist entry.
For Sophos, re-add the exclusion temporarily while investigating the root cause with the vendor.
Master Verification Checklist
ThreatLocker
☐ Agent deployed to all endpoints (portal count matches RMM count)
☐ Organization in Secured Mode (default-deny)
☐ Allowlist covers all approved business applications
☐ Ringfencing active for PowerShell/cmd (network share and internet access blocked)
☐ Ringfencing active for Office apps (child process spawning blocked)
☐ Elevation control configured with time-bound approvals (max 4 hours)
☐ Elevation requests generate email notifications to helpdesk
☐ All elevation events logged in Unified Audit
Sophos MDR
☐ Agent deployed to all endpoints
☐ Tamper protection enabled on all devices
☐ No wildcard exclusions for user profile directories
☐ All exclusions documented with reason, vendor reference, and review date
☐ Web control blocking malicious, phishing, and unrated sites
☐ Device control blocking USB storage (or read-only per client policy)
☐ MDR integration active and analysts monitoring
Defender for Endpoint ASR
☐ All 14 ASR rules in Block mode
☐ ASR telemetry flowing to M365 Defender portal
☐ ASR block events (Event ID 1121) appearing for attempted violations
☐ Exclusions minimal and documented
☐ No user-reported legitimate application breakage post-deployment
Annual Review
☐ ThreatLocker allowlist reviewed and stale entries removed
☐ Sophos exclusions reviewed (global and per-policy)
☐ Defender ASR exclusions reviewed
☐ Review documented in client SharePoint
☐ Next review date scheduled
Document History
Date
Author
Change
2026-03-26
Netier Security Engineering
Initial creation
SOP: Vulnerability Management
Document ID:NET-SOP-VULN-001 Version: 1.0 Effective Date: 2026-03-26 Next Review: 2026-09-26 Owner: Netier — Security & Cloud Engineering Classification: Internal TCF Section: 4.0 Review Cycle: Quarterly or after vendor portal/product changes
Run a test scan against a single representative target and verify:
# After scan completes, check for "Credentialed checks: yes" in scan results
In Nessus: open scan results > click a host > look for Plugin 19506 "Nessus Scan Information"
The output should contain:
Credentialed checks : yes
Patch management checks : (details)
In ConnectSecure, check the scan results for the target and verify the asset shows full software inventory (only possible with authenticated scanning).
Verification Checks
☐ Service account svc-vulnscan created and stored in Bitwarden
☐ Service account has local admin on all targets (verified by successful credentialed scan)
☐ Nessus scan results show "Credentialed checks: yes" (Plugin 19506) on all scanned hosts
☐ ConnectSecure scan results show full software inventory for scanned hosts
☐ Remote Registry service is running on Windows targets
☐ WMI and File and Printer Sharing firewall rules enabled on targets
☐ SSH key authentication working for Linux targets (test with manual SSH login)
Rollback
To revoke scan access: remove svc-vulnscan from Administrators group or Domain Admins, and disable the account.
Register-ScheduledTask -TaskName "KEV-Weekly-CrossReference" -Action $action -Trigger $trigger -Settings $settings -Principal $principal -Description "Weekly CISA KEV cross-reference against open vulnerability tickets"
Verification Checks
☐ CISA KEV catalog is being downloaded and parsed correctly (test script manually)
☐ KEV cross-reference runs after every scan completion
☐ Any CVE found in KEV is auto-escalated to P1 regardless of CVSS score
☐ P1 escalation note includes KEV details (required action, CISA due date)
☐ Security team receives immediate notification for KEV matches
☐ Weekly KEV sync scheduled task is running (check Task Scheduler or logs)
☐ KEV match logs are retained in C:\VulnScans\Logs\ for audit trail
Rollback
If KEV auto-escalation creates false urgency (e.g., KEV entry is for a product not in the client environment), manually downgrade the ticket with a note explaining the non-applicability.
The KEV cross-reference script is advisory; it does not modify scan configurations. To disable, stop the scheduled task:
Validate the finding: Check if the vulnerability is a true positive.
- Review the Nessus/ConnectSecure plugin output for the specific host.
- Check if the vulnerable software version matches what is installed (credentialed scan confirmation).
- If false positive: add note to ticket with justification, set status to Closed - False Positive, and add the plugin to the scanner's false positive suppression list.
Assess exploitability:
- Is the vulnerable service exposed externally? (If yes, treat as higher urgency)
- Is there a public exploit available? (Check Exploit-DB, Metasploit modules)
- Is it in the CISA KEV catalog? (If yes, auto-P1 per above section)
Determine remediation path:
- Patch available: Schedule patching via NinjaOne or WSUS.
Request a targeted re-scan of the affected host(s):
- In Nessus: create an ad-hoc scan targeting only the remediated host(s) with the same credentials.
- In ConnectSecure: trigger a manual scan for the specific asset from Assets > [Host] > Scan Now.
After re-scan completes, verify the vulnerability no longer appears:
- Open the re-scan results and confirm the specific plugin/CVE is absent.
- If the vulnerability persists, investigate: Was the patch applied correctly? Does it require a reboot? Is there a different instance of the vulnerable software?
Update the ConnectWise Manage ticket:
- Add the re-scan results as evidence (screenshot or exported PDF).
- Add internal note with: remediation action taken, date applied, re-scan date, and confirmation of resolution.
- Set ticket status to Closed - Resolved.
# Quick validation: check if a specific KB is installed
☐ Remediation SLA compliance rate is tracked and reported
☐ CISA KEV cross-reference logs are retained for audit
☐ Annual review completed with metrics and improvement recommendations
Rollback
Evidence collection is a reporting function with no system impact. No rollback needed.
If reports contain sensitive vulnerability details, ensure they are stored with appropriate access controls (client SharePoint permissions set to Security team only).
Master Verification Checklist
Scanner Deployment
☐ Nessus/ConnectSecure scanner installed and accessible
☐ Plugin database up to date (last update within 24 hours)
☐ Scanner can reach all target subnets
☐ Firewall rules configured for scanner-to-target access
Credentialed Scanning
☐ Service account svc-vulnscan created and stored in Bitwarden
Under Company > Settings > Branding, upload the client's logo and set brand colours to match their corporate identity.
Enable the uSecure Outlook Add-in for phishing report button:
- Navigate to Company > Settings > Phishing Report Button.
- Copy the add-in manifest URL.
- In the Microsoft 365 Admin Centre (https://admin.microsoft.com) for the client tenant, go to Settings > Integrated apps > Upload custom apps.
- Paste the manifest URL and deploy to All Users or a targeted security group.
Verify the deployment by sending a test email to a Netier engineer's mailbox in the client tenant and confirming the "Report Phishing" button appears in Outlook.
Verification Checks
☐ Client company created in uSecure with correct name
☐ Licence count matches agreement
☐ Directory sync connected and returning correct user count
☐ Notification sender name and reply-to configured
☐ Client branding (logo and colours) applied
☐ Outlook phishing report button add-in deployed and functional
☐ Test sync completed without errors
Rollback
If directory sync pulls incorrect users, navigate to Company > Settings > Directory Sync and disconnect the integration. Manually remove any incorrectly imported users under Company > Users.
If the Outlook add-in causes issues, remove it from Microsoft 365 Admin Centre > Integrated apps, select the uSecure add-in, and click Remove.
If the entire tenant needs to be removed, navigate to Admin > Companies, select the client, and click Archive Company. Do not permanently delete without Netier Security Lead approval.
2. Baseline Security Assessment
ISM Controls:ISM-0264 (Security Awareness Training)
Prerequisites
Client tenant fully onboarded in uSecure with all users imported
User directory sync verified (or CSV import confirmed)
Client onboarding kickoff date confirmed (assessment must be assigned within Week 1)
Step-by-Step Instructions
In the uSecure Partner Portal, navigate to the client company.
Go to Assess > Baseline Assessment.
Select uRisk Baseline Assessment (the default Netier template covers: phishing recognition, password hygiene, data handling, social engineering basics, physical security).
Under Assignment Settings:
- Target: All Users (or the specific security group if a phased rollout was agreed).
- Start Date: the client's onboarding kickoff date (must be within Week 1).
- Deadline: 10 business days from start date.
- Reminders: Enable at Day 3 and Day 7.
Click Schedule Assessment.
Monitor completion rates:
- Navigate to Assess > Reports > Baseline.
- Check daily during the assessment window.
- If completion is below 50% at Day 5, escalate to the client primary contact via email requesting they send an internal reminder.
Once the deadline passes, export the baseline results:
- Navigate to Assess > Reports > Baseline > Export.
- Download as PDF and CSV.
- Save the PDF to the client's compliance folder in SharePoint: Clients/{ClientName}/Compliance/Security Awareness/Baseline Assessment - {YYYY-MM}.pdf.
Review the baseline report with the client in the next scheduled service review meeting. Identify the three lowest-scoring categories to prioritise in the first quarter's training plan.
Verification Checks
☐ Baseline assessment assigned within Week 1 of client onboarding
☐ Assessment uses the Netier standard uRisk template
☐ Deadline set to 10 business days
☐ Reminders enabled at Day 3 and Day 7
☐ Completion rate monitored during assessment window
☐ Results exported and saved to client SharePoint compliance folder
☐ Lowest-scoring categories documented for training plan prioritisation
Rollback
If the assessment was assigned to the wrong user group, navigate to Assess > Baseline Assessment, cancel the active assessment, correct the target group, and reschedule.
If users report they cannot access the assessment, verify their email addresses in Company > Users and check spam/junk folders for the assignment notification.
- Template Selection: Select Randomised (uSecure will assign a random template to each user from the enabled template pool). This prevents users from warning each other about identical emails.
- Template Pool: Enable at least 8 templates from the following categories, rotating quarterly:
Export the campaign report as PDF and save to: Clients/{ClientName}/Compliance/Security Awareness/Phishing Reports/Phish Report - {YYYY-MM}.pdf.
Users who clicked or submitted credentials are automatically flagged for remedial training (see Section 5).
Verification Checks
☐ Campaign uses randomised templates (minimum 8 in pool)
☐ Send window spreads over 5 business days
☐ Tracking duration set to 7 days
☐ Landing page is Netier-branded education page
☐ Email whitelisting verified (Advanced Delivery policy in M365)
☐ Campaign report exported and filed after tracking period
☐ Users who failed are flagged for remedial training auto-enrollment
Rollback
If a campaign sends to the wrong user group or uses incorrect templates, navigate to Simulate > Campaigns, select the active campaign, and click Pause Campaign immediately. Contact uSecure support if emails have already been delivered and need to be recalled.
If users report the simulation emails are being blocked by spam filters, verify the Advanced Delivery policy in Microsoft 365 Security Centre > Email & Collaboration > Policies > Advanced Delivery and re-add the uSecure simulation domains.
4. Quarterly Core Training Modules
ISM Controls:ISM-0264 (Security Awareness Training), ISM-1784 (Ongoing Awareness)
- Target: All Users (or departmental groups if client has role-specific training requirements).
- Start Date: First Monday of the quarter month.
- Deadline: 20 business days from start date.
- Reminders: Enable at Day 5, Day 10, and Day 15.
- Completion Certificate: Enabled (users receive a PDF certificate on completion).
Click Schedule Assignment.
Monitor completion:
- Check weekly via Train > Reports > Course Completion.
- At Day 10, send a reminder to the client primary contact listing users below 50% completion.
- At Day 15, escalate non-completions to the client's HR or management contact if previously agreed.
After the deadline:
- Export the completion report as PDF and CSV.
- Save to: Clients/{ClientName}/Compliance/Security Awareness/Training Reports/Quarterly Training - {YYYY-QX}.pdf.
- Users who did not complete the assigned training are flagged and added to a ConnectWise ticket for client follow-up (see Section 5).
Verification Checks
☐ Quarterly modules match the annual rotation schedule
☐ Assignment targets correct user group
☐ Deadline set to 20 business days
☐ Reminders enabled at Day 5, Day 10, and Day 15
☐ Completion certificates enabled
☐ Completion monitored weekly during the assignment window
☐ Non-completions escalated at Day 15
☐ Final report exported and saved to client SharePoint folder
Rollback
If the wrong modules are assigned, navigate to Train > Courses, select the assignment, and click Cancel Assignment. Reassign the correct modules.
If users cannot access the training portal, verify their email addresses are correct and that training notification emails are not being filtered. Check the user's status under Company > Users to confirm they are Active.
5. Auto-Enrollment Remedial Training & ConnectWise Integration
ISM Controls:ISM-0264 (Security Awareness Training)
Prerequisites
ConnectWise Manage instance with API access configured for uSecure integration
ConnectWise Manage workflow WF-010 ("Security Awareness Remediation") created and active
uSecure remedial training courses configured in the template library
ConnectWise API member credentials stored securely (API keys in Netier's credential vault)
Step-by-Step Instructions
Configure auto-enrollment rules in uSecure:
- Navigate to the client company, then go to Settings > Automation Rules.
- Click + New Rule.
- Rule 1 — Phishing Failure Remediation:
- Trigger: User clicks a phishing simulation link OR submits credentials on a simulation landing page.
- Action: Auto-enroll user in "Identifying Phishing Emails" remedial course.
- Deadline: 10 business days from enrollment.
- Reminders: Day 3 and Day 7.
- Rule 2 — Repeat Offender Escalation:
- Trigger: User fails 2 or more phishing simulations within a rolling 90-day window.
- Action: Auto-enroll in "Advanced Phishing Defence" course AND trigger ConnectWise ticket.
- Deadline: 10 business days.
- Rule 3 — Training Non-Completion:
- Trigger: User does not complete assigned quarterly training by the deadline.
- Action: Auto-enroll in the same training course with a 5-business-day extension AND trigger ConnectWise ticket.
- Click Save for each rule.
Configure ConnectWise Manage integration:
- Navigate to Admin > Integrations > ConnectWise Manage.
- Enter the ConnectWise Manage API URL: https://au.myconnectwise.net/v4_6_release/apis/3.0.
- Enter the API Public Key and Private Key (retrieve from Netier credential vault — search "uSecure ConnectWise API").
- Set the Company ID to netier.
- Map ticket fields:
- Board: Service Desk
- Type: Security Awareness
- Subtype: Remediation Required
- Priority: Medium (escalate to High for repeat offenders)
- Status: New
- Set the Workflow ID to WF-010.
- Click Test Connection to verify, then Save.
When a ConnectWise ticket is created by uSecure (WF-010 trigger):
- The ticket summary follows the format: [SAT Remediation] {UserName} - {TriggerReason} - {ClientName}.
- The ticket body includes: user details, trigger event, assigned remedial course, and deadline.
- The Netier service desk triages the ticket and confirms the client's designated contact has been notified.
- Once the user completes the remedial training, uSecure updates the ticket status to Completed via the API.
Verify automation rules are firing correctly:
- After each monthly phishing campaign, check Settings > Automation Rules > Execution Log for the client.
- Confirm that users who clicked/submitted credentials have been auto-enrolled.
- Spot-check 2-3 users to ensure ConnectWise tickets were created for repeat offenders.
Verification Checks
☐ Auto-enrollment Rule 1 (phishing failure) configured and active
☐ Auto-enrollment Rule 2 (repeat offender escalation) configured and active
☐ Auto-enrollment Rule 3 (training non-completion) configured and active
☐ ConnectWise Manage API integration connected and tested
☐ Ticket field mappings correct (board, type, priority, workflow)
☐ WF-010 workflow active in ConnectWise Manage
☐ Automation execution log reviewed after each campaign cycle
☐ Repeat offender tickets created with High priority
Rollback
If automation rules are triggering incorrectly, navigate to Settings > Automation Rules, select the rule, and click Disable. Investigate the trigger conditions before re-enabling.
If ConnectWise tickets are being created with incorrect data, check the field mappings under Admin > Integrations > ConnectWise Manage and correct them. Manually close any erroneous tickets in ConnectWise.
If the ConnectWise API connection fails, verify the API keys are current and have not been rotated. Re-test the connection.
6. CyberCred Security Champions Program
ISM Controls:ISM-0264 (Security Awareness Training), ISM-1784 (Ongoing Awareness)
Prerequisites
Client opted into the CyberCred Security Champions program
CyberCred portal active at https://cyber.netier.team
Client users synced to the CyberCred platform (via uSecure integration or manual import)
Client primary contact briefed on the program structure and reward tiers
Step-by-Step Instructions
Access the CyberCred admin portal at https://cyber.netier.team/admin.
Navigate to Companies > Select Client > Program Settings.
Verify the points allocation matrix is configured:
| Activity | Points Awarded | Frequency Cap |
|----------|---------------|---------------|
| Complete a training module | 10 per module | No cap |
| Pass a phishing simulation (no click) | 15 per campaign | Monthly |
| Report a suspicious email via Outlook button | 5 per report | 3 per day max |
| Report a real phishing email (verified by SOC) | 25 per report | No cap |
| Attend a security briefing / lunch-and-learn | 20 per event | Quarterly |
| Complete the quarterly training set on time | 30 bonus | Quarterly |
- Platinum: 500 points — Digital badge + premium gift card ($50 value) + Security Champion certificate
- Diamond: 1,000 points — Digital badge + premium gift ($100 value) + Security Champion of the Year nomination + featured on cyber.netier.team Hall of Fame
Configure leaderboard settings:
- Navigate to Program Settings > Leaderboard.
- Enable Company Leaderboard (shows top 10 users within the client company).
- Enable Department Leaderboard (if client has departments mapped).
- Set leaderboard refresh frequency: Real-time.
- Enable Monthly Leaderboard Email to all participants (sent on the 1st of each month).
- Leaderboard is publicly visible at: https://cyber.netier.team/{client-slug}/leaderboard.
Configure uSecure integration for automatic point tracking:
- Navigate to Program Settings > Integrations > uSecure.
- Enter the uSecure API key for the client tenant (retrieve from uSecure > Company > Settings > API).
- Click Test Sync and verify a recent event is pulled through.
Launch the program:
- Navigate to Program Settings > Communications.
- Customise the launch email template with client branding.
- Schedule the launch email for the agreed program start date.
- Include: program overview, how points are earned, reward tiers, link to leaderboard.
Ongoing management (monthly):
- Review the leaderboard and verify points are accruing correctly.
- Process reward redemptions for users who reach a new tier:
- Navigate to Rewards > Pending Redemptions.
- Confirm the user's tier eligibility.
- Dispatch the reward (digital badges are automatic; physical rewards are coordinated via Netier operations).
- At the end of each quarter, generate a CyberCred summary report:
- Navigate to Reports > Quarterly Summary.
- Export as PDF and include in the client's quarterly service review pack.
Verification Checks
☐ Points allocation matrix matches the table above
☐ All five reward tiers configured with correct thresholds
☐ Company and department leaderboards enabled
☐ Monthly leaderboard email scheduled
☐ uSecure integration connected and syncing events
☐ Launch email customised with client branding and scheduled
☐ Reward redemptions processed within 5 business days of tier achievement
☐ Quarterly CyberCred summary report generated and filed
Rollback
If points are being awarded incorrectly, navigate to Program Settings > Points History and manually adjust the user's point balance. Document the correction.
If the uSecure integration stops syncing, check the API key validity under Integrations > uSecure and regenerate if needed.
If a client requests to pause the program, navigate to Program Settings > Status and set to Paused. This freezes all point accrual and hides the leaderboard. Points are retained for when the program resumes.
7. Reporting & Compliance Evidence Extraction
ISM Controls:ISM-0264 (Security Awareness Training), ISM-1784 (Ongoing Awareness)
Prerequisites
All previous sections operational (uSecure onboarded, baseline done, campaigns running, training assigned, CyberCred active)
Access to the client's compliance SharePoint folder
Knowledge of the client's compliance framework requirements (ISO 27001 A.6.3, ISM, IS18 PR4)
Step-by-Step Instructions
Monthly Evidence Pack (due by the 5th of each month):
- Log in to uSecure Partner Portal.
- Navigate to the client company.
- Export the following reports:
- Phishing Campaign Report (Simulate > Reports > Latest Campaign): PDF and CSV.
- Training Completion Report (Train > Reports > All Courses): PDF showing completion rates for the current quarter.
- User Risk Score Report (Assess > Reports > Risk Scores): PDF showing current risk posture per user.
- Save all exports to: Clients/{ClientName}/Compliance/Security Awareness/Monthly Evidence/{YYYY-MM}/.
Quarterly Evidence Pack (due within 10 business days of quarter end):
Annual Review Evidence (due within 20 business days of financial year end):
- Export the annual summary from uSecure: Reports > Annual Summary.
- Include year-over-year trend data for: click rates, report rates, training completion, risk scores.
- Include CyberCred annual participation and tier achievements.
- Present findings and recommendations in the client's annual security review meeting.
- Save to: Clients/{ClientName}/Compliance/Security Awareness/Annual Review/{YYYY}/.
Verification Checks
☐ Monthly evidence pack exported and filed by the 5th of each month
☐ Quarterly evidence pack compiled within 10 business days of quarter end
☐ All exports include both PDF and CSV formats where applicable
☐ Compliance framework mapping table reviewed and current
☐ Annual review evidence compiled and presented
☐ SharePoint folder structure follows the standard naming convention
☐ Evidence is sufficient to satisfy ISO A.6.3, ISM-0264, ISM-1784, and IS18 PR4
Rollback
If reports contain incorrect data (e.g., wrong date range), re-export with the correct parameters and replace the filed document. Add a note to the filename: {Report} - {YYYY-MM} - CORRECTED.pdf.
If SharePoint access is unavailable, save evidence locally and upload within 2 business days of access restoration.
8. Master Verification Checklist
uSecure Platform Setup & Client Tenant Onboarding
☐ Client company created in uSecure with correct name
☐ Licence count matches agreement
☐ Directory sync connected and returning correct user count
☐ Notification sender name and reply-to configured
☐ Client branding (logo and colours) applied
☐ Outlook phishing report button add-in deployed and functional
☐ Test sync completed without errors
Baseline Security Assessment
☐ Baseline assessment assigned within Week 1 of client onboarding
☐ Assessment uses the Netier standard uRisk template
☐ Deadline set to 10 business days
☐ Reminders enabled at Day 3 and Day 7
☐ Completion rate monitored during assessment window
☐ Results exported and saved to client SharePoint compliance folder
☐ Lowest-scoring categories documented for training plan prioritisation
Monthly Automated Phishing Simulation Campaigns
☐ Campaign uses randomised templates (minimum 8 in pool)
☐ Send window spreads over 5 business days
☐ Tracking duration set to 7 days
☐ Landing page is Netier-branded education page
☐ Email whitelisting verified (Advanced Delivery policy in M365)
☐ Campaign report exported and filed after tracking period
☐ Users who failed are flagged for remedial training auto-enrollment
Quarterly Core Training Modules
☐ Quarterly modules match the annual rotation schedule
☐ Assignment targets correct user group
☐ Deadline set to 20 business days
☐ Reminders enabled at Day 5, Day 10, and Day 15
☐ Completion certificates enabled
☐ Completion monitored weekly during the assignment window
☐ Non-completions escalated at Day 15
☐ Final report exported and saved to client SharePoint folder
Auto-Enrollment Remedial Training & ConnectWise Integration
☐ Auto-enrollment Rule 1 (phishing failure) configured and active
☐ Auto-enrollment Rule 2 (repeat offender escalation) configured and active
☐ Auto-enrollment Rule 3 (training non-completion) configured and active
☐ ConnectWise Manage API integration connected and tested
☐ Ticket field mappings correct (board, type, priority, workflow)
☐ WF-010 workflow active in ConnectWise Manage
☐ Automation execution log reviewed after each campaign cycle
☐ Repeat offender tickets created with High priority
CyberCred Security Champions Program
☐ Points allocation matrix matches the defined values
☐ All five reward tiers configured with correct thresholds
☐ Company and department leaderboards enabled
☐ Monthly leaderboard email scheduled
☐ uSecure integration connected and syncing events
☐ Launch email customised with client branding and scheduled
☐ Reward redemptions processed within 5 business days of tier achievement
☐ Quarterly CyberCred summary report generated and filed
Reporting & Compliance Evidence Extraction
☐ Monthly evidence pack exported and filed by the 5th of each month
☐ Quarterly evidence pack compiled within 10 business days of quarter end
☐ All exports include both PDF and CSV formats where applicable
☐ Compliance framework mapping table reviewed and current
☐ Annual review evidence compiled and presented
☐ Evidence is sufficient to satisfy ISO A.6.3, ISM-0264, ISM-1784, and IS18 PR4
9. Document History
Date
Author
Change
2026-03-26
Netier Security Engineering
Initial creation
SOP: Endpoint Management (MDM/UEM)
Document ID:NET-SOP-MDM-001 Version: 1.0 Effective Date: 2026-03-26 Next Review: 2026-09-26 Owner: Netier — Security & Cloud Engineering Classification: Internal TCF Section: 6.0 Review Cycle: Quarterly or after vendor portal/product changes
☐ Windows Firewall enabled on all profiles (Domain, Private, Public)
Rollback
To remove a configuration profile: Navigate to Devices > Configuration, select the profile, go to Assignments, remove the device group, then delete the profile. Devices will revert to local policy on next sync.
To remove BitLocker encryption (requires valid business justification and Security Lead approval): Disable the encryption policy assignment. On the device, run manage-bde -off C: as local administrator. Monitor decryption progress with manage-bde -status.
To revert Windows Update settings: Delete the update ring assignment. Devices will fall back to local Windows Update settings.
echo "Require Password After Screensaver: $ask_for_password (1 = Yes)"
echo ""
echo "=== Check Complete ==="
Verification Checks
☐ All macOS devices enrolled via Automated Device Enrollment
☐ ABM token active and not expired
☐ FileVault enabled with recovery keys escrowed to Intune
☐ SIP enabled (csrutil status = enabled) verified via compliance policy
☐ Gatekeeper enabled
☐ Firewall enabled with stealth mode
☐ Screen lock requires password immediately after sleep
☐ macOS update policy assigned with correct deferral periods
☐ Compliance policy detecting and flagging non-compliant devices
Rollback
To remove FileVault: Disable the FileVault policy assignment. On the device, go to System Settings > Privacy & Security > FileVault > Turn Off FileVault. Requires local admin credentials and Security Lead approval.
To remove a configuration profile from managed devices: Unassign the device group from the profile in Intune. The profile will be removed at next device check-in.
If a compliance policy is incorrectly blocking users, set the compliance policy action to "Mark noncompliant" only (remove any retire/wipe actions) while investigating.
3. iOS/iPadOS Device Management
ISM Controls:ISM-1406 (Hardening OS), ISM-1745 (Application Control), ISM-0869 (Screen Lock)
Prerequisites
Apple Business Manager (ABM) account linked to Intune
APN certificate active in Intune
Entra ID groups for iOS/iPadOS devices created (Corporate-Owned and BYOD if applicable)
VPP (Volume Purchase Program) tokens configured for app deployment
Step-by-Step Instructions
3.1 Device Enrollment
For corporate-owned devices (ADE):
- Navigate to Devices > Enrollment > Apple > Enrollment Program Tokens > {Token} > Profiles > + Create Profile > iOS/iPadOS.
To remove device restrictions: Unassign the device group from the restrictions profile. For supervised devices, a profile removal may require a device wipe if the enrollment profile is locked.
To ease BYOD restrictions: Modify the App Protection Policy to loosen data transfer settings. Changes propagate at next app check-in.
ISM Controls:ISM-1406 (Hardening OS), ISM-1745 (Application Control), ISM-0869 (Screen Lock)
Prerequisites
Managed Google Play account linked to Intune (navigate to Devices > Enrollment > Android > Managed Google Play to verify)
Entra ID groups for Android devices (Corporate-Owned Work Profile and BYOD Work Profile)
Android Enterprise fully managed enrollment configured for corporate-owned devices
Android Enterprise Work Profile enrollment configured for BYOD
Step-by-Step Instructions
4.1 BYOD Work Profile Enrollment
Navigate to Devices > Enrollment > Android > Android Enterprise > Personal Devices with Work Profile.
Verify enrollment is set to Allow.
Users install the Intune Company Portal app from Google Play, sign in with their Entra ID credentials, and follow the prompts to create a Work Profile.
The Work Profile creates an isolated container on the device — corporate apps and data are separated from personal.
4.2 Corporate-Owned Fully Managed Enrollment
Navigate to Devices > Enrollment > Android > Android Enterprise > Corporate-Owned Fully Managed User Devices.
Create an enrollment token or use QR code / NFC provisioning.
On a factory-reset device, tap the screen 6 times at the welcome screen to enter QR provisioning mode.
Scan the QR code generated from Intune. The device enrolls as fully managed.
4.3 Device Restrictions — Work Profile (BYOD)
Navigate to Devices > Configuration > + Create > New Policy.
Platform: Android Enterprise. Profile type: Work Profile > Device Restrictions.
Name: Android-BYOD-WP-{ClientName}.
Configure:
Work Profile Settings:
- Copy/paste between work and personal profiles: Block
- Screen capture in work profile: Block
- Contact sharing from work to personal profile: Block (caller ID allowed)
To remove the Work Profile on a BYOD device: The user can remove the Company Portal app, which triggers Work Profile deletion (corporate data wiped, personal data preserved).
To unenroll a corporate-owned fully managed device: Navigate to Devices > {Device} > Wipe. This factory-resets the device. Ensure client approval before proceeding.
To loosen restrictions temporarily: Edit the device restrictions profile, adjust settings, and save. Changes propagate at next device check-in (typically within 8 hours, or force sync from Company Portal).
5. Linux (Ubuntu/RHEL) Endpoint Hardening
ISM Controls:ISM-1406 (Hardening OS), ISM-1914 (Endpoint Encryption), ISM-1409 (OS Patching)
Prerequisites
Microsoft Intune licence that includes Linux management (Microsoft 365 E3/E5 or Intune Plan 2)
Linux devices running Ubuntu 22.04+ or RHEL 8+
Microsoft Edge and Intune agent installed on the Linux device
Entra ID registration completed on the Linux device
SSH access to the Linux device for initial setup (or configuration management tool such as Ansible)
Step-by-Step Instructions
5.1 Intune Enrollment for Linux
On the Linux device, install the Microsoft Intune app:
Launch the Intune Portal app and sign in with the user's Entra ID credentials.
Complete the enrollment flow. The device will appear in Intune under Devices > Linux.
5.2 LUKS Disk Encryption
LUKS encryption must be configured at OS install time or via manual partition encryption. Intune can enforce a compliance check for encryption but cannot enable LUKS remotely.
During OS installation, select Encrypt the new installation (Ubuntu) or Encrypt my data (RHEL).
Set a strong LUKS passphrase (minimum 20 characters, stored in Netier credential vault for the client).
For existing devices without LUKS, back up data and reinstall with encryption enabled (coordinate with client for downtime window).
Verify encryption status:
# Check LUKS encryption status
sudo cryptsetup luksDump /dev/sda3 # adjust partition as needed
lsblk -f | grep -i luks
Configure Intune compliance policy to require encryption:
To disable unattended upgrades: sudo systemctl disable --now unattended-upgrades (Ubuntu) or sudo systemctl disable --now dnf-automatic.timer (RHEL).
To unenroll from Intune: Run the Intune Portal app on the Linux device and select "Unenroll". This removes the Intune management profile but does not affect local configurations.
6. Master Verification Checklist
Windows 10/11
☐ All Windows devices enrolled in Intune
☐ CIS Level 1 baseline configuration profile applied and compliant
☐ BitLocker enabled with XTS-AES 256 on all OS and fixed drives
☐ BitLocker recovery keys stored in Entra ID
☐ Windows Update for Business ring assigned (feature updates deferred 14d, quality updates deferred 2d)
☐ Screen auto-lock at 15 minutes confirmed
☐ Consumer experience features disabled
☐ Windows Firewall enabled on all three profiles
macOS
☐ All macOS devices enrolled via Automated Device Enrollment
☐ FileVault enabled with recovery keys escrowed to Intune
☐ SIP enabled verified via compliance policy
☐ Gatekeeper enabled
☐ Firewall enabled with stealth mode
☐ Screen lock requires password immediately after sleep
☐ macOS update policy assigned with correct deferral periods
iOS/iPadOS
☐ Corporate-owned devices enrolled via ADE in supervised mode
- Login banner: Authorised access only. All activity is monitored and logged.
Register the device to FortiCloud (https://support.fortinet.com) and activate FortiGuard licences.
Configure interfaces:
- Navigate to Network > Interfaces.
- Configure WAN1: ISP-provided settings.
- Configure LAN (port1 or aggregate): client internal gateway IP.
- Disable unused interfaces: Navigate to each unused interface and set Administrative Access to None.
Apply default-deny baseline:
- Navigate to Policy & Objects > Firewall Policy.
- Verify the implicit deny rule at the bottom of the policy table (ID 0, action Deny, logging enabled).
- Remove any factory-default allow-all policies.
- Create explicit allow policies (same pattern as WatchGuard above).
- Enable logging on all policies: set Log Allowed Traffic to "All Sessions" and Log Violation Traffic to enabled on the implicit deny.
FortiGate CLI Alternative:
# FortiGate CLI — accessed via SSH or console
config system global
set admin-lockout-threshold 3
set admin-lockout-duration 300
set admin-https-redirect enable
set admin-http-redirect enable
set timezone 67
set hostname "{ClientName}-FW01"
set admintimeout 15
set pre-login-banner enable
set pre-login-banner-message "Authorised access only. All activity is monitored and logged."
end
Restrict management access to Netier IPs only
config system interface
edit "wan1"
set allowaccess ping
# No HTTPS/SSH on WAN — management via LAN or VPN only
next
edit "lan"
set allowaccess ping https ssh
set trust-ip 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
next
end
Create Netier management address group
config firewall address
edit "Netier-Mgmt-IPs"
set type iprange
set start-ip {NETIER_PUBLIC_IP_START}
set end-ip {NETIER_PUBLIC_IP_END}
next
end
config system admin
edit "admin"
set trusthost1 {NETIER_PUBLIC_IP}/32
set trusthost2 100.64.0.0/10
next
end
Firmware management:
- Check current firmware: System > Firmware.
- Policy: Maintain N-1 stable release (e.g., if 7.6.x is latest stable, run 7.4.x latest patch or 7.6.x minus one minor).
- Critical CVE patches: Apply within 48 hours of vendor advisory.
- Non-critical firmware upgrades: Apply within 30 days during a scheduled maintenance window.
- Always back up the configuration before upgrading firmware.
Verification Checks
☐ Admin passphrase set to minimum 16 characters and stored in credential vault
☐ Implicit deny rule present at the bottom of all policy tables
☐ No factory-default allow-all rules remain
☐ Explicit allow rules created only for documented required traffic
☐ Management interface access restricted to Netier IPs only
☐ WAN management interface access disabled
☐ HTTPS management enforced (HTTP disabled)
☐ Idle timeout set to 15 minutes
☐ Login banner configured
☐ Logging enabled on all policies (including deny rules)
☐ Firmware at N-1 stable or patched for critical CVEs within 48 hours
☐ Configuration backed up before any firmware upgrade
☐ Unused interfaces disabled
Rollback
If a firewall policy blocks legitimate traffic, identify the policy by reviewing logs (Dashboard > Traffic Monitor on WatchGuard; Log & Report > Forward Traffic on FortiGate), create an appropriate allow rule, and document the change.
If a firmware upgrade causes instability, restore the previous configuration backup and downgrade firmware via the vendor's documented procedure.
If management access is accidentally locked out, use the console port for recovery. On FortiGate: reset the admin password via console with config system admin / edit admin / set password {new} / end. On WatchGuard: factory reset via the reset button (hold 10 seconds) and restore from backup.
2. IPS/IDS Configuration
ISM Controls:ISM-1528 (Network Security), ISM-0631 (Firewall Rulebase)
- Navigate to System > Subscription Services > Signature Updates.
- Set update frequency: Every 1 hour.
Configure IPS exceptions (only when a documented false positive is confirmed):
- Navigate to Security Services > Intrusion Prevention > Exceptions.
- Add the specific signature ID with a justification note.
- Exceptions must be reviewed quarterly and removed if the false positive no longer occurs.
2.2 Fortinet IPS
Navigate to Security Profiles > Intrusion Prevention.
Create or edit the IPS sensor: Netier-IPS-Sensor-{ClientName}.
Configure signature actions:
- Critical severity: Action = Block
- High severity: Action = Block
- Medium severity: Action = Block
- Low severity: Action = Monitor (Log Only)
- Informational: Action = Monitor (Log Only)
Enable IPS deep packet inspection for SSL traffic (requires SSL/TLS inspection profile — see note below).
Apply the IPS sensor to all firewall policies:
- Navigate to Policy & Objects > Firewall Policy.
- Edit each policy and under Security Profiles, enable IPS and select the Netier-IPS-Sensor-{ClientName} profile.
FortiGate CLI Alternative:
config ips sensor
edit "Netier-IPS-Sensor"
config entries
edit 1
set status enable
set log enable
set severity critical high
set action block
next
edit 2
set status enable
set log enable
set severity medium
set action block
next
edit 3
set status enable
set log enable
set severity low info
set action pass
set log-packet enable
next
end
next
end
Enable automatic signature updates:
- Navigate to System > FortiGuard > Update.
- Verify IPS definitions are updating (check last update timestamp).
- Set update schedule: Push-based (real-time from FortiGuard) or scheduled hourly.
Verification Checks
☐ IPS enabled on all relevant firewall policies
☐ High and Critical severity signatures set to Block mode
☐ Medium severity signatures set to Block mode
☐ Low and Informational signatures set to Monitor/Alarm (log only)
☐ Automatic signature updates enabled and updating at least hourly
☐ IPS exceptions documented with justification (reviewed quarterly)
☐ IPS logs visible in the logging platform (WatchGuard Cloud or FortiAnalyzer/syslog)
Rollback
If IPS is blocking legitimate traffic (false positive): Identify the signature ID from the IPS log, add it to the exceptions list with documentation, and notify the Netier Security Lead for quarterly review.
If IPS causes performance degradation: Temporarily change Medium severity to Monitor (log only) to reduce processing load while investigating the cause. Do not disable IPS entirely without Security Lead approval.
3. VPN Configuration
ISM Controls:ISM-1182 (Encrypted Communications), ISM-0520 (Remote Access)
Prerequisites
Firewall hardened per Section 1
VPN licence active (if applicable — most enterprise firewalls include VPN in the base licence)
MFA solution configured: RADIUS server (e.g., NPS with Azure MFA extension) or SAML IdP (Entra ID)
VPN client software approved and tested (WatchGuard Mobile VPN / FortiClient)
Client VPN policy approved (who gets VPN access, from which devices)
Step-by-Step Instructions
3.1 Protocol Enforcement
Block legacy VPN protocols:
- PPTP: Do NOT configure any PPTP VPN tunnels. If legacy PPTP tunnels exist, migrate users to IKEv2 or SSL VPN and delete the PPTP configuration.
- L2TP without IPsec: Do NOT configure L2TP without IPsec encryption. If L2TP/IPsec is in use, migrate to IKEv2 (preferred) or SSL VPN.
Approved protocols:
- IKEv2/IPsec (preferred for site-to-site and client VPN): Strong encryption, native OS client support, best performance.
- SSL VPN (alternative for client VPN when IKEv2 is not feasible): Firewalled to specific portal URL on port 443.
3.2 WatchGuard IKEv2 VPN with MFA
Navigate to VPN > Mobile VPN > IKEv2.
Enable Mobile VPN with IKEv2.
Configure Phase 1 settings:
- Authentication: Certificate-based (preferred) or EAP with RADIUS
- Encryption: AES-256-GCM
- Hash: SHA-384 or SHA-256
- DH Group: 20 (NIST P-384) or 21 (NIST P-521)
- SA Lifetime: 28800 seconds (8 hours)
Configure Phase 2 settings:
- Encryption: AES-256-GCM
- SA Lifetime: 3600 seconds (1 hour)
- Perfect Forward Secrecy: Enabled (DH Group 20)
Configure RADIUS authentication for MFA:
- Navigate to Authentication > Servers > RADIUS.
- Add the RADIUS server (NPS with Azure MFA extension):
- IP: (NPS server internal IP)
- Port: 1812
- Shared secret: (stored in Netier credential vault under {ClientName} - RADIUS Shared Secret)
- Timeout: 60 seconds (to allow for MFA prompt)
- Navigate to Authentication > Authentication Policy.
- Add the RADIUS server to the authentication chain for VPN users.
Define VPN user group:
- Navigate to Authentication > Users and Groups.
- Create a group VPN-Users and add authorised users.
- Map this group to the IKEv2 VPN configuration.
Configure split tunnelling (if approved by client):
- Under the IKEv2 settings, define the allowed resources (client internal subnets only).
- Do NOT route all internet traffic through the VPN unless the client specifically requires it for compliance.
Configure client-side:
- Windows: Use the native IKEv2 VPN client (Settings > Network & Internet > VPN > Add VPN).
- macOS/iOS: Use the native IKEv2 VPN client (System Settings > VPN > Add VPN Configuration).
- Distribute VPN configuration via Intune VPN profile for managed devices.
3.3 Fortinet SSL VPN with SAML MFA
Navigate to VPN > SSL-VPN Settings.
Configure:
- Listen on port: 443 (or 10443 if port 443 is used for other services)
- Listen on interface: WAN1
- Restrict access: Enable Source IP restriction to known countries (AU at minimum; add others per client travel requirements)
- Server certificate: Valid publicly trusted certificate (Let's Encrypt or purchased CA cert)
- Authentication: SAML (preferred for Entra ID integration)
Configure SAML authentication with Entra ID:
- In the Entra ID portal (https://entra.microsoft.com), navigate to Enterprise Applications > + New Application > FortiGate SSL VPN (from the gallery).
- On the FortiGate, navigate to User & Authentication > Single Sign-On > + Create New.
- Upload the Federation Metadata XML from Entra ID.
- Map the Entra ID groups to FortiGate user groups for VPN access.
Create SSL VPN firewall policies:
- Navigate to Policy & Objects > Firewall Policy.
- Source: SSL VPN tunnel interface, VPN user group.
- Destination: Internal subnets (specific resources, not "all").
- Service: Only required services (e.g., RDP, HTTPS, SMB).
- Enable logging: All sessions.
FortiGate CLI Alternative:
config vpn ssl settings
set status enable
set servercert "{CERT_NAME}"
set tunnel-ip-pools "SSL-VPN-Pool"
set port 443
set source-interface "wan1"
set source-address "Geo-AU"
set idle-timeout 300
set auth-timeout 28800
set dtls-tunnel enable
set ssl-min-proto-ver tls1-2
end
config vpn ssl web portal
edit "tunnel-access"
set tunnel-mode enable
set web-mode disable
set split-tunneling enable
set split-tunneling-routing-address "{CLIENT_INTERNAL_SUBNETS}"
set ip-pools "SSL-VPN-Pool"
next
end
Verification Checks
☐ PPTP and L2TP (without IPsec) protocols are not configured anywhere on the firewall
☐ IKEv2/IPsec or SSL VPN is the only configured VPN protocol
☐ VPN encryption uses AES-256 (GCM preferred)
☐ MFA enforced for all VPN connections (RADIUS or SAML)
☐ RADIUS timeout set to 60 seconds (to accommodate MFA prompt)
☐ VPN user group restricted to authorised users only
☐ Split tunnelling configured (if approved) with specific internal subnets only
☐ SSL VPN portal uses a valid publicly trusted certificate
☐ SSL VPN restricted to approved source countries (geo-IP filtering)
☐ VPN firewall policies restrict access to specific services (not "allow all")
☐ VPN sessions logged with full detail
Rollback
If VPN MFA is locking out users, verify the RADIUS/SAML server is reachable from the firewall. Temporarily add a local user with a strong password for break-glass access (document and remove after resolution).
If VPN performance is degraded, check the firewall CPU/memory utilisation. Consider reducing the number of concurrent SSL VPN users or moving to IKEv2 (less CPU-intensive).
If a VPN protocol migration is incomplete and users cannot connect, maintain the old VPN configuration alongside the new one until all users have migrated, then decommission the old protocol.
4. VLAN Design & Segmentation
ISM Controls:ISM-1528 (Network Security), ISM-0631 (Firewall Rulebase)
Prerequisites
Managed switches deployed (e.g., Cisco Catalyst, Meraki, Aruba, UniFi — must support 802.1Q VLAN tagging)
Firewall configured with VLAN subinterfaces or dedicated interfaces per VLAN
Client network design document with approved VLAN plan and IP addressing scheme
Trunk ports configured between switches and the firewall
Step-by-Step Instructions
4.1 Standard VLAN Template
Apply the following VLAN design for all new client deployments. Adjust VLAN IDs and subnets per the client's IP addressing plan.
- Allowed TO: SIP provider external IPs and ports (SIP TCP/UDP 5060-5061, RTP UDP 10000-20000)
- Allowed TO: Voice gateway / PBX in Server VLAN (if on-prem)
- Blocked TO: All other VLANs and general internet
Guest VLAN (50):
- Allowed TO: Internet only (HTTPS TCP 443, HTTP TCP 80, DNS UDP 53 to filtered DNS)
- Blocked TO: All internal VLANs (complete isolation)
- Rate limited: Per-client bandwidth cap (e.g., 10 Mbps down / 5 Mbps up)
- Captive portal: Enabled (acceptance of Acceptable Use Policy)
IoT VLAN (60):
- Allowed TO: Specific whitelisted outbound destinations only (e.g., cloud management portals for printers, cameras):
- Printer cloud: vendor-specific domains
- Camera NVR: Server VLAN NVR IP only
- Building management: vendor cloud portals
- Blocked TO: All internal VLANs except explicitly whitelisted
- Blocked FROM: Internet inbound (no port forwarding to IoT devices)
- All other outbound traffic: Denied
Document all inter-VLAN rules in the client's firewall rulebase spreadsheet and save to: Clients/{ClientName}/Network/Firewall Rules - {Date}.xlsx.
Switch Configuration Example (Cisco IOS):
! Create VLANs
vlan 10
name Management
vlan 20
name Server
vlan 30
name Client
vlan 40
name Voice
vlan 50
name Guest
vlan 60
name IoT
! Trunk port to firewall
interface GigabitEthernet0/1
description Trunk to Firewall
switchport mode trunk
switchport trunk allowed vlan 10,20,30,40,50,60
switchport trunk native vlan 999
spanning-tree portfast trunk
! Access port for client workstation
interface GigabitEthernet0/10
description Client Workstation
switchport mode access
switchport access vlan 30
switchport voice vlan 40
spanning-tree portfast
spanning-tree bpduguard enable
! Access port for IoT device (printer)
interface GigabitEthernet0/20
description IoT - Printer
switchport mode access
switchport access vlan 60
spanning-tree portfast
spanning-tree bpduguard enable
! Disable unused ports
interface range GigabitEthernet0/40 - 48
shutdown
switchport access vlan 999
description UNUSED - DISABLED
Verification Checks
☐ All standard VLANs created (Management, Server, Client, Voice, Guest, IoT)
☐ Default VLAN 1 is not used for any production traffic
☐ Trunk ports between switches and firewall carry only required VLANs
☐ Native VLAN set to an unused VLAN (e.g., 999), not VLAN 1
☐ Inter-VLAN firewall policies follow least privilege (documented per client)
☐ Guest VLAN completely isolated from all internal VLANs
☐ Guest VLAN rate limited and captive portal enabled
☐ IoT VLAN whitelisted outbound only (no unrestricted internet access)
☐ Management VLAN accessible only from Netier management IPs
☐ Unused switch ports shut down and assigned to an unused VLAN
☐ Firewall rulebase documented and saved to client SharePoint
Rollback
If VLAN segmentation breaks an application, identify the traffic flow (source VLAN, destination VLAN, port/protocol) from firewall logs, create a targeted allow rule, and document the exception.
If a trunk port misconfiguration causes a VLAN to lose connectivity, verify the trunk allowed VLAN list and native VLAN settings on both the switch and the firewall.
To revert to a flat network (emergency only, Security Lead approval required): Remove VLAN assignments from switch ports, set all ports to a single VLAN, and update the firewall to route on the single subnet.
5. DNS Filtering
ISM Controls:ISM-1528 (Network Security), ISM-1782 (Web Content Filtering)
Prerequisites
DNS filtering platform account provisioned: Cloudflare Gateway (https://dash.teams.cloudflare.com) or Cisco Umbrella (https://dashboard.umbrella.com)
Firewall configured to intercept and redirect DNS queries (prevent DNS bypass)
Client DHCP scopes configured to assign the DNS filter IPs as the primary DNS servers
Client agreement covers DNS filtering and acceptable use
Step-by-Step Instructions
5.1 Cloudflare Gateway Setup
Log in to Cloudflare Zero Trust at https://dash.teams.cloudflare.com.
Navigate to Gateway > DNS Locations > + Add Location.
Name: {ClientName} - {SiteName}.
Configure:
- Source IP: Client's public WAN IP (for IP-based identification).
- DNS-over-HTTPS endpoint: Note the unique DoH URL for this location.
- Assigned DNS IPs: Note the Cloudflare Gateway resolver IPs assigned to this location.
Navigate to Gateway > Policies > DNS Policies > + Create Policy.
Enter the client's public WAN IP and name: {ClientName} - {SiteName}.
Navigate to Policies > DNS Policies > + Add Policy.
Create the standard blocking policy:
- Name: Netier-Standard-{ClientName}.
- Security Settings:
- Block: Malware, Command & Control Callbacks, Phishing, Cryptomining, Newly Seen Domains
- Content Categories:
- Block: Adult, Gambling, Weapons, Hate/Discrimination, Drugs (adjust per client)
- Application Settings:
- Block or monitor specific SaaS applications per client policy
Enable logging:
- Navigate to Admin > Log Management.
- Enable full DNS logging.
- Set retention to 90 days.
- Configure S3 export if the client requires longer retention.
Configure the client's DHCP scopes to use Umbrella DNS IPs:
- Primary DNS: 208.67.222.222
- Secondary DNS: 208.67.220.220
- Or use the site-specific Umbrella Virtual Appliance IPs if deployed.
5.3 Prevent DNS Bypass (Firewall Rule)
On the firewall, create a rule to block all DNS traffic to destinations other than the approved DNS filter IPs:
- Source: All internal VLANs
- Destination: Any (NOT the approved DNS filter IPs)
- Service: DNS (UDP/TCP 53)
- Action: Deny (with logging)
Create a separate allow rule above the deny:
- Source: All internal VLANs
- Destination: Approved DNS filter IPs only
- Service: DNS (UDP/TCP 53)
- Action: Allow
Additionally, block DNS-over-HTTPS (DoH) bypass for non-managed browsers:
- Block outbound TCP 443 to known public DoH providers (e.g., 8.8.8.8, 1.1.1.1 — unless using Cloudflare Gateway DoH directly).
- On managed endpoints, configure the browser via Intune to use the approved DoH resolver or disable DoH.
Verification Checks
☐ DNS filtering platform account provisioned and location configured
☐ Standard blocking policy applied (malware, botnet, phishing, cryptomining)
☐ Content filtering categories configured per client policy
☐ Activity logging enabled with 90-day retention
☐ DHCP scopes on all VLANs point to the DNS filter IPs
☐ Firewall rule blocks DNS to any destination other than approved filter IPs
☐ DNS bypass via DoH addressed (firewall block or endpoint configuration)
☐ Test blocked domain resolution from a client device (e.g., nslookup a known-blocked test domain)
☐ Test allowed domain resolution works correctly
Rollback
If DNS filtering blocks a legitimate business-critical domain, add it to the allow list in the DNS filtering platform immediately, then investigate whether the block was a false positive or a policy misconfiguration.
If DNS filtering causes widespread connectivity issues (e.g., platform outage), temporarily change DHCP DNS servers to a public resolver (e.g., 8.8.8.8 / 8.8.4.4) and notify the client. Revert to DNS filter IPs once the platform is restored.
Do not disable the firewall DNS bypass prevention rule unless temporarily troubleshooting — restore it immediately after.
6. Configuration Backup & Change Management
ISM Controls:ISM-1528 (Network Security)
Prerequisites
Backup platform provisioned: Unimus (https://unimus.net), Auvik (https://my.auvik.com), or Oxidized (self-hosted)
Network devices accessible via SSH or HTTPS API from the backup platform
Dedicated service account on each network device for backup access (read-only where possible)
Backup storage location with encryption at rest
Change management process documented in ConnectWise Manage
Step-by-Step Instructions
6.1 Unimus Backup Configuration
Log in to Unimus at the instance URL (e.g., https://unimus.netier.team or cloud instance).
Navigate to Devices > + Add Device.
For each network device (firewalls, switches, APs, routers):
- Enter the device IP address (use the Management VLAN IP).
- Set the connection protocol: SSH (preferred) or HTTPS API.
- Enter the backup service account credentials (stored in Netier credential vault under {ClientName} - Network Backup Account).
- Set the device type (auto-detect or manual: WatchGuard, FortiGate, Cisco IOS, etc.).
Navigate to Settings > Backup Schedule.
Set the backup schedule:
- Frequency: Daily at 01:00 AEST.
- Retention: 90 days (minimum per TCF requirement).
- On-change backup: Enable (triggers an immediate backup when a configuration change is detected).
For changes that are classified as high-risk (firewall rule changes, firmware upgrades, VLAN changes):
- Require peer review by a second Netier engineer.
- Schedule during an approved maintenance window.
- Take a manual configuration backup immediately before the change.
- Test and verify after the change.
- Document the result in the ConnectWise ticket.
For changes triggered by a detected configuration drift (Unimus/Auvik alert):
- Investigate the change: Was it authorised?
- If unauthorised, restore the previous configuration from backup.
- Document the incident and escalate per the incident response process.
Verification Checks
☐ All network devices added to the backup platform (Unimus/Auvik/Oxidized)
☐ Daily backup schedule configured at 01:00 AEST
☐ Backup retention set to 90 days minimum
☐ On-change backup enabled (if supported by the platform)
☐ Backup failure alerts configured and sent to noc@netier.com.au
☐ First backup verified for each device (complete configuration captured)
☐ Change management process documented and followed for all network changes
☐ High-risk changes require peer review and approved maintenance window
☐ Unauthorised configuration changes detected and investigated
Rollback
To restore a device configuration from backup: In Unimus/Auvik, navigate to the device's backup history, select the desired version, and use the "Push Config" feature (if supported). Otherwise, manually paste the backup configuration via SSH/console.
If the backup platform itself is unavailable, use the most recent manual backup stored in the client's SharePoint folder: Clients/{ClientName}/Network/Config Backups/.
If a configuration restore causes issues, restore the configuration that was active immediately before the restore attempt (the backup platform should have captured it via on-change backup).
7. Network Access Control (802.1X)
ISM Controls:ISM-0520 (Remote Access), ISM-1528 (Network Security)
Prerequisites
RADIUS server deployed: Microsoft NPS (Network Policy Server) on Windows Server, or cloud RADIUS (e.g., Portnox, SecureW2)
PKI infrastructure for EAP-TLS: Internal CA or cloud-managed CA (e.g., Intune SCEP/PKCS certificate profiles)
If 802.1X locks out all devices on a switch, disable 802.1X on the affected ports:
interface range GigabitEthernet0/1 - 48
no authentication port-control auto
no dot1x pae authenticator
no mab
Then investigate and fix the RADIUS/NPS configuration before re-enabling.
If certificate deployment fails via Intune, verify the SCEP/PKCS connector is healthy in Intune > Tenant Administration > Connectors. Temporarily fall back to PEAP-MSCHAPv2 (username/password) while troubleshooting certificate issues.
If the NPS server is unavailable, switches with a "critical VLAN" configured will place devices on a restricted VLAN. Restore NPS service as a priority.
8. Master Verification Checklist
Firewall Initial Hardening
☐ Admin passphrase set and stored in credential vault
☐ Implicit deny rule present at bottom of all policy tables
☐ No factory-default allow-all rules remain
☐ Management interface restricted to Netier IPs only
☐ WAN management access disabled
☐ HTTPS management enforced
☐ Idle timeout set to 15 minutes
☐ Logging enabled on all policies
☐ Firmware at N-1 stable or critical CVEs patched within 48 hours
☐ Unused interfaces disabled
IPS/IDS
☐ IPS enabled on all firewall policies
☐ High/Critical/Medium severity signatures set to Block
☐ Low/Informational signatures set to Monitor
☐ Automatic signature updates enabled (hourly)
☐ Exceptions documented and reviewed quarterly
VPN
☐ PPTP and L2TP (without IPsec) not configured
☐ IKEv2 or SSL VPN using AES-256 encryption
☐ MFA enforced on all VPN connections
☐ VPN user group restricted to authorised users
☐ Split tunnelling configured with specific subnets only
☐ SSL VPN uses valid publicly trusted certificate
☐ VPN sessions fully logged
VLAN Design & Segmentation
☐ All standard VLANs created (Mgmt, Server, Client, Voice, Guest, IoT)
☐ Default VLAN 1 not used for production traffic
☐ Native VLAN set to unused VLAN (not VLAN 1)
☐ Guest VLAN completely isolated from internal VLANs
☐ IoT VLAN whitelisted outbound only
☐ Management VLAN accessible from Netier IPs only
☐ Unused switch ports shut down
DNS Filtering
☐ DNS filtering platform configured with standard blocking policy
☐ Activity logging enabled with 90-day retention
☐ All DHCP scopes point to DNS filter IPs
☐ Firewall blocks DNS to non-approved destinations
☐ DNS bypass via DoH addressed
Configuration Backup
☐ All network devices added to backup platform
☐ Daily backups at 01:00 AEST with 90-day retention
☐ On-change backup enabled
☐ Backup failure alerts configured
☐ First backup verified for each device
☐ Change management process followed for all changes
Network Access Control (802.1X)
☐ NPS server installed and healthy
☐ RADIUS clients configured for all switches and APs
☐ EAP-TLS policy with correct VLAN assignment
☐ MAB policy for non-802.1X devices on IoT VLAN
☐ Certificate deployment via Intune verified
☐ Managed device authenticated via EAP-TLS (tested)
☐ Unmanaged device authenticated via MAB (tested)
☐ Unknown device denied access (tested)
9. Document History
Date
Author
Change
2026-03-26
Netier Security Engineering
Initial creation
SOP: Backup & Disaster Recovery
Document ID:NET-SOP-BDR-001 Version: 1.0 Effective Date: 2026-03-26 Next Review: 2026-09-26 Owner: Netier — Security & Cloud Engineering Classification: Internal TCF Section: 8.0 Review Cycle: Quarterly or after vendor portal/product changes
- Description: Include the test procedure checklist from this SOP.
Attach the relevant SOP section link to the ticket description for engineer reference.
Verification Checks
☐ Recurring tickets exist for all clients, all activities, at the correct frequency
☐ Tickets are assigned to a named team member
☐ Completed tickets have evidence attached before closing
☐ Overdue tickets are escalated (CW Manage SLA triggers)
Rollback
If a recurring ticket was created with the wrong frequency, edit the recurrence pattern in ConnectWise. Do not delete and recreate (preserves ticket history).
Master Verification Checklist
Veeam
☐ Backup job configured with application-aware processing
Write-Host "$($unmatched.Count) applications found in inventory but not in ThreatLocker allowlist."
For each unmatched application:
- If legitimate business software: add to ThreatLocker allowlist via Policies > Application Control > Add Application.
- If unapproved: verify ThreatLocker is blocking it. If not, create a deny rule.
- If unknown: investigate with the client contact before taking action.
Document the reconciliation in the ConnectWise monthly review ticket.
Verification Checks
☐ Software inventory is current (polled within the last 24 hours)
☐ Reconciliation report generated and reviewed monthly
☐ All unapproved software either blocked in ThreatLocker or approved with justification
☐ No outdated versions of critical applications (browsers, Java, Adobe) present
☐ Reconciliation documented in the ConnectWise monthly review ticket
Rollback
If a legitimate application is incorrectly blocked in ThreatLocker, add it to the allowlist immediately.
Use ThreatLocker Unified Audit to identify block events and determine the correct hash/certificate to allow.
Alert-to-ConnectWise Ticket Routing
ISM Controls:ISM-1143
Prerequisites
NinjaOne PSA integration with ConnectWise Manage enabled
ConnectWise API credentials configured in NinjaOne
Board, type, and priority mappings defined
Step-by-Step Instructions
1. Configure PSA Integration
Navigate to NinjaOne > Administration > Integrations > PSA.
Select ConnectWise Manage.
Enter the ConnectWise Manage API credentials:
- Site URL:https://na.myconnectwise.net/v2025_1/ (or current version).
- Company ID:netier.
- Public Key: From CW Manage > System > Members > API Keys.
- Private Key: Stored in Bitwarden ("ConnectWise API - NinjaOne Integration").
Click Test Connection — verify success.
Enable Bi-directional sync: ticket status changes in CW reflect in NinjaOne, and vice versa.
2. Configure Alert-to-Ticket Mappings
Navigate to Administration > Integrations > PSA > Ticket Mappings.
Configure mappings:
NinjaOne Alert Type
CW Board
CW Type
CW Priority
Device Offline (Server)
Service Desk
Alert - Offline
Priority 1 - Emergency
Device Offline (Workstation)
Service Desk
Alert - Offline
Priority 4 - Low
Disk Space Critical
Service Desk
Alert - Disk Space
Priority 2 - Medium
Disk Space Warning
Service Desk
Alert - Disk Space
Priority 3 - Low
CPU/Memory Sustained
Service Desk
Alert - Performance
Priority 3 - Low
Security Service Stopped
Security Alerts
Alert - Security
Priority 1 - Emergency
Patch Failure
Service Desk
Alert - Patching
Priority 3 - Low
Failed Login Brute Force
Security Alerts
Alert - Security
Priority 2 - Medium
Backup Failure
Service Desk
Alert - Backup
Priority 2 - Medium
Hardware SMART Warning
Service Desk
Alert - Hardware
Priority 2 - Medium
Set Auto-close behaviour: When the alert condition resolves in NinjaOne, automatically close the CW ticket with resolution note "Auto-resolved — condition returned to normal."
3. Verify Ticket Routing
Trigger a test alert (e.g., temporarily lower a disk space threshold on a test device).
Verify a ConnectWise ticket is created with the correct:
- Board and type.
- Priority level.
- Company mapping (ticket is associated with the correct CW company).
- Device information in the ticket body.
Resolve the alert condition and verify the CW ticket is auto-closed.
Verification Checks
☐ PSA integration connected and test passes
☐ All alert types mapped to correct CW boards, types, and priorities
☐ Company mapping correct (NinjaOne org -> CW company)
☐ Test alert creates a CW ticket within 5 minutes
☐ Auto-close works when alert condition resolves
☐ No orphaned alerts (NinjaOne alerts without corresponding CW tickets)
Rollback
If ticket routing is misconfigured (wrong board/priority), update the mapping in NinjaOne PSA settings.
If the integration fails, check API credentials haven't expired and CW Manage is accessible.
Misrouted tickets can be moved to the correct board in ConnectWise Manage directly.
Pre-Reboot & Post-Verification Automation
ISM Controls:ISM-1493, ISM-1807
Prerequisites
Patch policy configured with scheduled reboot windows
Pre/post scripts created in NinjaOne script library
Server role-specific scripts for DC, Exchange, Hyper-V, SQL
Step-by-Step Instructions
1. Pre-Reboot Script (All Servers)
Deploy as a NinjaOne Pre-Patch Script attached to server patch policies.
Create sub-pages per client using a consistent naming convention:
Client Documentation (CLIENTDOC)
├── [ClientCode] — Client Name
│ ├── Network & Infrastructure
│ │ ├── Network Diagram
│ │ ├── IP Address Register
│ │ ├── Firewall Rules
│ │ └── VLAN Configuration
│ ├── Identity & Access
│ │ ├── Entra ID Configuration
│ │ ├── Conditional Access Policies
│ │ └── Service Accounts Register
│ ├── Backup & DR
│ │ ├── Backup Configuration
│ │ ├── DRP Document
│ │ └── DR Test Reports
│ ├── Security
│ │ ├── E8 Maturity Assessment
│ │ ├── ThreatLocker Configuration
│ │ └── Vulnerability Scan Results
│ └── Contacts & Escalation
│ ├── Client Contact List
│ └── Vendor Contacts
├── [NextClient] — Client Name
│ └── ...
Apply permissions: Netier staff have View/Edit; no external access unless explicitly approved.
3. Create the Compliance Frameworks Space
Click Spaces > Create a space.
Configure:
- Space name:Compliance Frameworks
- Space key:COMPLY
- Description: "TCF baselines, ISM control mappings, Essential Eight assessments, evidence registers, and compliance policies."
Create the page hierarchy:
Compliance Frameworks (COMPLY)
├── Trusted Compliance Framework (TCF)
│ ├── TCF Control Matrix
│ ├── TCF Section Mapping to SOPs
│ └── TCF Evidence Register
├── Essential Eight
│ ├── E8 Maturity Model Overview
│ ├── Per-Client E8 Assessments
│ │ ├── [ClientCode] — ML Assessment
│ │ └── ...
│ └── E8 Remediation Tracking
├── ISM Controls
│ ├── ISM Control Register
│ ├── ISM Implementation Status
│ └── ISM Gap Analysis Template
├── Policies
│ ├── Information Security Policy
│ ├── Acceptable Use Policy
│ ├── Incident Response Policy
│ ├── Data Classification Policy
│ └── Vendor Management Policy
└── Evidence Library
├── YYYY-QX Evidence Collection
└── Audit Reports
Apply permissions: Restricted to Security Engineering leads and Compliance team.
Verification Checks
☐ All three spaces created: INTSOP, CLIENTDOC, COMPLY
☐ Page hierarchies established per the structures above
☐ Space descriptions are accurate and meaningful
☐ Permissions applied before any content is added (see Permission Scheme section)
☐ No anonymous or public access on any space
☐ Confluence navigation sidebar shows the correct hierarchy
Rollback
Spaces can be renamed via Space Settings > General > Space details.
Spaces should never be deleted. If a space is created in error, archive it: Space Settings > General > Delete this space (moves to trash, recoverable for 60 days).
Page trees can be reorganised by drag-and-drop or by moving pages via ... > Move.
Entra ID SSO & Conditional Access for Confluence
ISM Controls:ISM-0888, ISM-0041
Prerequisites
Microsoft Entra ID (Azure AD) with P1 or P2 licence
Atlassian Cloud organisation linked to Atlassian Access (required for SAML SSO)
Atlassian Access subscription active
Global Administrator or Application Administrator role in Entra ID
Step-by-Step Instructions
1. Configure SAML SSO in Atlassian Access
Log in to Atlassian Admin (https://admin.atlassian.com).
Navigate to Security > SAML single sign-on.
Click Add SAML configuration.
Note the SP Entity ID and SP ACS URL — these are needed in Entra ID.
2. Create Enterprise Application in Entra ID
Log in to Microsoft Entra Admin Centre (https://entra.microsoft.com).
Navigate to Identity > Applications > Enterprise applications.
Click New application > Create your own application.
Name: Atlassian Cloud (Confluence + Jira).
Select Integrate any other application you don't find in the gallery (Non-gallery).
Click Create.
3. Configure SAML SSO
In the enterprise application, navigate to Single sign-on > SAML.
Under Basic SAML Configuration, click Edit:
- Identifier (Entity ID): Paste the SP Entity ID from Atlassian Admin.
- Reply URL (ACS URL): Paste the SP ACS URL from Atlassian Admin.
- Persistent browser session: Disabled (no "stay signed in").
Set policy to Report-only first, monitor for 7 days, then switch to On.
Verification Checks
☐ SAML SSO configured and domain verified in Atlassian Access
☐ SSO enforcement enabled — users cannot bypass SSO with local Atlassian passwords
☐ Conditional Access policy in place requiring MFA for Confluence access
☐ Test login: user is redirected to Microsoft login, completes MFA, and lands in Confluence
☐ Failed login (non-compliant device, no MFA): access is blocked as expected
☐ Sign-in logs in Entra ID show Confluence logins going through the CA policy
Rollback
If SSO breaks and users are locked out, disable Enforce SSO in Atlassian Admin. Users can then log in with Atlassian credentials while the issue is resolved.
If the Conditional Access policy blocks legitimate users, switch it to Report-only immediately.
Certificate expiry: SAML certificates expire (typically 3 years). Set a calendar reminder 30 days before expiry to rotate the certificate. Rotation procedure: generate new cert in Entra ID, upload to Atlassian Admin, then remove old cert.
Permission Scheme Configuration
ISM Controls:ISM-0888, ISM-1602, ISM-0041
Prerequisites
Confluence spaces created (see Space Structure section)
Entra ID groups synced to Atlassian (via SCIM provisioning or manual group creation)
Permission scheme design agreed by Security Engineering leads
Step-by-Step Instructions
1. Define Atlassian Groups
Create the following groups in Atlassian Admin > Directory > Groups:
Group Name
Members
Purpose
confluence-admins
Security Engineering leads (2-3 people)
Full admin on all spaces
confluence-editors-sop
All Netier engineers
Edit access to Internal SOPs space
confluence-editors-client
Assigned engineers per client
Edit access to Client Documentation
confluence-editors-comply
Security Engineering + Compliance
Edit access to Compliance Frameworks
confluence-viewers
All Netier staff
View-only access across all spaces
Sync these groups from Entra ID via SCIM:
In Atlassian Admin > Directory > User provisioning.
Enable SCIM provisioning with Entra ID.
In Entra ID, configure Provisioning on the Atlassian Cloud enterprise app:
- List of documents due for review (or "review all pages in space with Next Review date in this period").
- Checklist: verify accuracy, update procedures, confirm ISM control mappings, update version number and review date.
Click Save.
3. Document Review Process
When a review is triggered (CW ticket arrives):
Open the CW ticket and note the documents to be reviewed.
For each document in the Confluence space:
a. Open the page and read through all sections.
b. Verify all procedures are still accurate (portal paths, CLI commands, tool versions).
c. Check that ISM control mappings are still correct (cross-reference with the latest ISM release).
d. Update any outdated content.
e. If changes were made:
- Increment the version number (e.g., 1.0 to 1.1 for minor, 2.0 for major rewrite).
- Update the Effective Date to today.
- Update the Next Review date.
- Add an entry to the Document History table.
- Add a change note in the Confluence page save dialog (mandatory).
f. If no changes were needed:
- Update only the Next Review date (advance by the review cycle).
- Add a Document History entry: "Reviewed — no changes required."
Close the CW ticket with a summary of documents reviewed and changes made.
4. Version Control
Confluence provides built-in page version history. Enforce the following practices:
Every save must include a change note. Navigate to the page editor > click Publish > enter a meaningful change note (e.g., "Updated Veeam backup section to reflect v12.2 changes").
Never use "Revert to this version" without explicit approval from a confluence-admins member. Reverting discards all intermediate changes.
To compare versions: open a page > click ... > Page history > Compare between versions.
For major rewrites, create the new version as a draft, have it peer-reviewed, then publish.
5. Document Archival
When a document is no longer current (deprecated tool, decommissioned client, etc.):
Do NOT delete the page. Deletion removes audit history.
Move the page to the Archive section within the space:
- Click ... > Move on the page.
- Select the Archive parent page as the destination.
Add the label archived to the page.
Add a banner at the top of the page:
/info
This document has been archived as of [DATE]. It is retained for historical reference only.
Replacement document: [link to new document, if applicable]
Remove the page from any navigation shortcuts or pinned items.
Verification Checks
☐ All documents follow the approved template structure
☐ Document IDs follow the naming convention NET-{TYPE}-{ABBREV}-{SEQ}
☐ Labels applied to all pages (document type, TCF section, ISM controls)
☐ CW recurring tickets exist for all review cycles
☐ All documents have a valid Next Review date that has not passed
☐ Page history shows change notes on every save
☐ No documents are deleted — deprecated documents are archived
☐ Version numbers increment on every change
Rollback
If a page is accidentally deleted, check the Space Trash (Space Settings > Manage content > Trash) and restore within 60 days.
If a page is incorrectly edited, use Page history > Revert to restore the previous version (requires confluence-admins approval).
If a document is archived prematurely, move it back to the active section and remove the archived label.
Provide exports to auditors via a time-limited SharePoint link (not a permanent Confluence guest account). See External Sharing section.
Verification Checks
☐ Page history is enabled and recording changes (this is on by default in Confluence Cloud)
☐ Organisation audit log is accessible and contains recent events
☐ Audit log can be exported to CSV successfully
☐ Page export (PDF/HTML) works and includes metadata (author, date, version)
☐ Exports are provided to auditors via secure, time-limited channels only
Rollback
Audit logs cannot be deleted or modified in Confluence Cloud — this is by design for compliance.
If an export fails, verify the Atlassian API token has not expired and regenerate if needed.
ConnectWise Manage Knowledge Base Integration
ISM Controls:ISM-0888
Prerequisites
ConnectWise Manage access with knowledge base permissions
Confluence pages published for each relevant SOP/runbook
Convention for linking CW KB articles to Confluence source of truth
Step-by-Step Instructions
1. CW Manage Knowledge Base Strategy
The ConnectWise Manage knowledge base is used as a quick-reference layer for common tasks, while Confluence remains the source of truth for full SOPs and documentation.
CW KB articles should:
Contain a brief summary (1-2 paragraphs) of the procedure.
Include a direct link to the full Confluence page.
Be tagged with relevant CW categories for searchability during ticket resolution.
2. Create a CW KB Article Linked to Confluence
In ConnectWise Manage > System > Knowledge Base.
Click New Article.
Configure:
- Title: Match the SOP title (e.g., "SOP: Backup & Disaster Recovery").
- Category: Map to the relevant CW category (e.g., "Backup", "Security", "Monitoring").
- Board: Link to the board where related tickets are managed.
- Resolution:
Quick Reference: [Brief 2-3 sentence summary of the SOP scope]
Full SOP: https://netier.atlassian.net/wiki/spaces/INTSOP/pages/PAGE_ID
Document ID: NET-SOP-BDR-001
Last Reviewed: 2026-03-26
Next Review: 2026-09-26
Note: Always refer to the Confluence page for the latest version. This KB article
is a pointer only.
Click Save.
When engineers are working tickets, they can search the CW KB to find the relevant SOP link.
3. Maintain Synchronisation
When a Confluence SOP is updated, update the corresponding CW KB article's "Last Reviewed" date.
Add this as a step in the Document Review Process (see Document Lifecycle section).
Include it in the CW recurring review ticket checklist:
☐ Organisation audit log accessible and exportable
☐ Page export (PDF/HTML) tested and functional
ConnectWise Integration
☐ CW KB articles exist for all SOPs
☐ Articles link to Confluence source pages
☐ Articles are categorised and searchable
☐ Last Reviewed dates synchronised with Confluence
External Sharing
☐ Global external sharing disabled
☐ Anonymous and public link access disabled
☐ No stale collaboration spaces (all have expiry tickets)
☐ Quarterly external user audit scheduled
Document History
Date
Author
Change
2026-03-26
Netier Security Engineering
Initial creation
PART 4
Operational Plans
Incident Response Plan (IRP)
Document ID:NET-OP-IRP-001
Version: 1.0
Effective Date: 2026-03-26
Next Review: 2026-09-26
Owner: Netier — GRC / Security Operations
Classification: Internal
1. Overview & Objectives
This Incident Response Plan (IRP) defines the structured approach Netier uses to detect, classify, respond to, and recover from cybersecurity incidents. It fulfills the requirements of ISO 27001 (A.16), SOCI Act, DISP, and the Privacy Act 1988 (AU).
2. Roles and Responsibilities (The SIRT)
The Security Incident Response Team (SIRT) is activated during any P1 or P2 security incident.
| P4 (Low) | Anomalous login blocked by Conditional Access, spam influx. | Next Business Day | Automated closure / standard review. |
4. The 6-Phase Response Process
4.1 Preparation
Maintain the Lifecycle & Vulnerability Engine (LVE) to ensure all asset inventories and patching baselines are accurate.
Conduct bi-annual tabletop exercises.
Ensure immutable backups (DRP) are tested and isolated.
4.2 Identification
Alerts triggered via EDR, SIEM, LVE, or user reports.
The SOC verifies the alert to rule out false positives.
Incident is formally declared and classified (P1-P4).
4.3 Containment
Short-Term: Disconnect affected endpoints from the network (via NinjaOne/EDR isolation). Disable compromised Entra ID accounts. If the MSP toolstack is at risk, utilize the Global Kill Switch to sever API connections.
Long-Term: Deploy enhanced monitoring, rotate all suspected compromised credentials via Bitwarden/Keeper, implement strict geo-blocking.
4.4 Eradication
Remove malware, delete unauthorized persistence mechanisms (scheduled tasks, run keys, forwarding rules in Exchange).
Patch the exploited vulnerability utilizing the LVE workflow.
4.5 Recovery
Restore systems from immutable, known-good backups.
Re-enable network access in a phased approach (Canary ring validation).
Continuous monitoring of recovered assets for 72 hours to ensure no re-infection.
4.6 Lessons Learned
Post-Incident Review (PIR) completed within 7 days for P1/P2 incidents (target), 14 days hard SLA for all incidents.
Update baselines, CA policies, and training materials based on findings.
| T+14d | +14 calendar days | PIR completed (P1/P2: 7-day target); corrective actions logged in CW; baselines updated | Incident Commander |
4.8 Global Kill Switch Procedure
The Global Kill Switch is a pre-planned emergency disconnection sequence executed when the MSP toolstack itself is compromised (e.g., supply chain attack, NinjaOne/CW breach).
Disconnection Steps (execute in order):
Revoke API tokens: Disable all NinjaOne, CW Manage, ThreatLocker, and Sophos Central API keys from a pre-prepared offline credential store (Keeper vault on isolated device).
Disable GDAP/DAP relationships: Remove delegated admin privileges from the Partner Center to sever tenant access.
Block outbound connections: Apply pre-staged firewall rules (saved as "KILLSWITCH" policy) on WatchGuard/FortiGate devices to block all traffic to NinjaOne, CW, and compromised vendor IP ranges.
Isolate CT100: Shut down the Netier Compliance Engine/LVE container on Proxmox to prevent lateral movement via the automation platform.
Rotate all shared secrets: Immediately rotate all Break Glass account passwords, FIDO2 re-enrollment for admin accounts, and API secrets.
Notify all clients: Pre-drafted communication template sent via secondary channel (mobile/SMS, not email if email is compromised).
Recovery: Dual-authorisation required (Incident Commander + Managing Director) to re-enable any API connection or GDAP relationship. Each reconnection verified in isolation before proceeding to the next.
5. Mandatory Reporting Protocols
ACSC / ASD (SOCI Act & DISP): Cyber security incidents affecting critical infrastructure or defense supply chains MUST be reported to the ACSC within 12 hours of confirmation.
OAIC (Privacy Act): Any Notifiable Data Breach (NDB) involving PII that is likely to result in serious harm must be reported within 72 hours.
Client Notification: Primary contacts notified within 2 hours of a confirmed P1/P2 incident affecting their environment.
Business Continuity Plan (BCP)
Document ID:NET-OP-BCP-001
Version: 1.0
Effective Date: 2026-03-26
Next Review: 2026-09-26
Owner: Netier — GRC / Security Operations
Classification: Internal
1. Overview & Purpose
This Business Continuity Plan (BCP) outlines the strategies and procedures to ensure Netier can maintain critical operational functions and client services during a significant disruption. It aligns with ISO 22301, the SOCI Act, and APRA CPS 234.
2. Scope of Disruptions
This plan covers the following primary disaster scenarios:
Loss of Physical Facility: Total loss or inaccessibility of Netier's Canberra or Brisbane offices.
Loss of Critical Core System: Outage of NinjaOne, ConnectWise, Azure AD, or the LVE/Netier Compliance Engine platforms.
Loss of Key Personnel: Unavailability of key staff due to illness, pandemic, or emergency.
Widespread Telecommunications/Power Outage: Regional internet or power failure.
3. Critical Functions & Recovery Objectives
Every core Netier function is mapped against a Maximum Tolerable Period of Disruption (MTPD) and a Recovery Time Objective (RTO).
| Critical Function | Tool / System | RTO | MTPD |
| :--- | :--- | :--- | :--- |
| Emergency Support / Service Desk | ConnectWise PSA / Teams Phone | 1 Hour | 4 Hours |
Infrastructure: All critical MSP toolstacks are SaaS-based (CW, NinjaOne, M365) or accessible via Zero Trust Network Access (ZTNA) / Cloudflare Tunnels.
Communication: Internal coordination switches to Microsoft Teams and secondary mobile channels.
4.2 Loss of Critical Core System
NinjaOne Outage: Support shifts to reactive, guided user-assisted remote control (e.g., fallback to Microsoft Quick Assist (built into Windows 10/11)) and manual verification. Automated LVE patching halts.
ConnectWise PSA Outage: Incident tracking falls back to a secured, pre-provisioned SharePoint list/Excel matrix until PSA restoration.
CT100 (Netier Compliance Engine/LVE) Failure: Compliance scanning and automated firmware updates are paused. Failover to manual dashboard checks. CT100 recovery handled via the Disaster Recovery Plan (DRP).
4.3 Loss of Key Personnel
Cross-training is mandatory. At least two personnel must be documented as capable of executing critical tier processes (e.g., LVE orchestrator deployment, Global Kill Switch activation).
Review Frequency: The BCP is reviewed and updated annually or following significant changes to the Netier technology stack.
Testing: A BCP tabletop exercise simulating a critical system failure is conducted annually.
Distribution: A current, offline copy of this BCP is distributed to the Netier executive team securely.
Disaster Recovery Plan (DRP)
Document ID:NET-OP-DRP-001
Version: 1.0
Effective Date: 2026-03-26
Next Review: 2026-09-26
Owner: Netier — GRC / Security Operations
Classification: Internal
1. Overview
The Disaster Recovery Plan (DRP) defines the technical processes and procedures to recover Netier's IT infrastructure, data, and critical applications in the event of a catastrophic failure, cyber-attack, or hardware destruction. It directly supports the Business Continuity Plan (BCP) and maps to Essential Eight (E8) ML3, ISM, and ISO 27001.
To protect against ransomware and systemic failures, Netier enforces the following strict backup architectures:
Immutability: All critical backups must be written to immutable storage (WORM - Write Once Read Many) preventing deletion or alteration before the retention period expires.
Offline/Offsite Isolation: Backups must be mathematically and physically separated from the primary production domain (e.g., stored in Cloudflare R2, AWS Deep Glacier, or physically isolated NAS).
Authentication Separation: Backup infrastructure (consoles and storage targets) MUST NOT be joined to the primary Active Directory domain or Entra ID tenant. They require entirely separate, dedicated credentials managed via Keeper.
Encryption: Backups must be encrypted at rest (AES-256) and in transit (TLS 1.2+), with encryption keys managed securely and separately from the primary infrastructure.
Retention: Daily backups retained for 30 days, Weekly for 12 weeks, Monthly for 12 months (unless client compliance dictates otherwise, e.g., 7 years for financial data).
3. Disaster Classification & RTOs
Tier 1 (Critical): Core MSP Systems (CT100, Vaults, Primary AD if applicable). RTO: 4 Hours.
Isolate: Disconnect the compromised/failed host from the network.
Provision: Provision a clean hypervisor environment (Proxmox/ESXi) on secondary hardware or a cloud compute instance.
Restore: Initiate a bare-metal/full-VM restoration from the immutable backup console (e.g., Veeam).
Verify Integrity: Boot the VM in an isolated sandbox VLAN. Run AV/EDR scans and verify database integrity (e.g., PostgreSQL pg_checksums) BEFORE reconnecting to the production network.
4.2 Active Directory Forest Recovery
(Required if all Domain Controllers are compromised)
Identify the most recent clean backup prior to the incident.
Restore the Primary DC into an isolated network.
Perform an Authoritative Restore (NTDSUTIL).
Seize FSMO roles.
Clean metadata of compromised DCs.
Build and promote NEW Domain Controllers (do not restore secondary DCs from backups to avoid USN rollback).
Reset all user and admin passwords globally via script before enabling client network access.
4.3 Cloud Data (M365 / SharePoint)
Initiate granular or full site restoration using the M365 backup tool (e.g., AFI.ai).
Route restored files to a dedicated "Recovery Folder" to prevent overwriting newer, intact data unless a full point-in-time rollback is authorized.
5. Testing and Validation
Regular testing is the only way to ensure recovery capability.
Enterprise Tier Clients: Full VM/Bare-metal restoration tests conducted Quarterly.
Professional Tier Clients: Restoration tests conducted Bi-Annually.
Automated Verification: Use Netier Compliance Engine/LVE (planned) to automatically poll backup success logs and screenshot verifications, flagging any lack of valid backups within a 24-hour window as an SLA breach.
Classify information assets by sensitivity and criticality
M365 Sensitivity Labels (Purview); asset register in ConnectWise Manage
Sensitivity labels: OFFICIAL, OFFICIAL:Sensitive, PROTECTED (where applicable); auto-labeling policies for email/SharePoint; hardware assets tracked in CW Manage with lifecycle status
Intune remote wipe capability for managed devices; physical media: certificate of destruction; drives: ATA Secure Erase or physical destruction
Intune wipe logs, destruction certificates
Essential
5. Access Control
Implement identity management and authentication
M365/Entra ID with Conditional Access; FIDO2 MFA
Conditional Access policies: require MFA for all users; block legacy auth; require compliant device; location-based policies; session controls (1hr for admin portals)
Entra ID Conditional Access policy export, sign-in logs
Essential
5. Access Control
Manage privileged access
Entra PIM (JIT activation); Break Glass accounts; LAPS
PIM: max 4hr activation window; approval required for Global Admin; Break Glass: 2 accounts, excluded from CA, monitored via alert rules; LAPS: 14-day password rotation on local admin; 1-hour post-authentication reset
PIM activation logs, Break Glass sign-in alerts, LAPS audit (Intune)
Professional
5. Access Control
Enforce least privilege and separation of duties
Role-based access in Entra ID; ThreatLocker ringfencing
Named admin accounts separate from daily-use accounts; ThreatLocker application ringfencing prevents lateral tool abuse; Entra RBAC with scoped admin roles
Entra role assignments, ThreatLocker ringfencing policies
Professional
5. Access Control
Review access rights regularly
Entra ID Access Reviews; quarterly privilege audits
Entra ID Access Reviews: automated monthly reviews for privileged roles (Enterprise tier — requires Entra ID Governance licence); manual quarterly reviews with documented evidence (Professional/Essential tier). Stale account detection (90 days inactive = disabled)
BitLocker XTS-AES 256 via Intune; TLS 1.2 minimum enforced on all services (TLS 1.0/1.1 disabled); M365 data encrypted at rest (Microsoft-managed keys; CMK available for Enterprise)
DMARC aggregate reports, Defender threat explorer, email authentication records (DNS)
Essential
8. Communications Security
DNS filtering and web security
Cloudflare Gateway / Cisco Umbrella; ZTNA
DNS-layer filtering blocking malware, phishing, and policy-violating categories; ZTNA replacing traditional VPN for remote access (identity-aware, per-app tunnels)
DNS filtering logs, ZTNA access policies, blocked category reports
Professional
8. Communications Security
Firmware and network device patching
WatchGuard/Fortinet firmware management
Firmware maintained at N-1 stable release; patched within 30 days of release; critical CVEs patched within 48 hours; change tickets for all firmware updates
Firmware version audit, patch tickets (CW Manage)
Essential
9. System Acquisition & Development
Secure development and testing practices
CIS Benchmarks for baseline config; Intune configuration profiles
CIS hardened baselines deployed via Intune (Windows 10/11, macOS); configuration drift detection; test environments for major deployments; acceptance criteria defined in project scope
New systems scanned before production deployment; ThreatLocker learning mode captures application behavior before enforcement; Intune compliance check required before Conditional Access grants access
Mandatory SOC2/ISO27001 review; data sovereignty tracking
All critical vendors require SOC2 Type II or ISO 27001 certification; data sovereignty tracked (AU-preferred); vendor risk register maintained; annual review of critical vendor certifications
Vendor risk register (Confluence), SOC2/ISO27001 certificates, data sovereignty matrix
Shared responsibility matrix published per service tier; security requirements in vendor contracts (encryption, breach notification, audit rights); supply chain risk assessment for critical components
PIR conducted within 10 business days (14 calendar days) of incident closure; root cause analysis; corrective actions tracked in CW Manage; lessons learned fed into training (uSecure) and policy updates
PIR reports, corrective action tickets, updated policies
Professional
12. Business Continuity
Business continuity planning and DRP
Veeam DRP; tiered DRP testing schedule
DRP documentation per client; RTO/RPO defined per system criticality; immutable backups (ransomware-resilient); DRP testing: Enterprise quarterly, Professional bi-annual, Essential annual
DRP documents, test results, RTO/RPO matrices
Essential
12. Business Continuity
Backup integrity and restore testing
Veeam restore testing; AFI.ai verification
Automated backup verification (Veeam SureBackup where available); manual restore testing per DRP schedule; M365 restore testing (AFI.ai) included in DRP exercises
Restore test logs, SureBackup reports, DRP exercise records
Technical compliance: continuous via vulnerability scanning and Intune compliance; policy/process: 6-12 month review cadence (Confluence page expiry); external audit support (ISO 27001 certification audit)
Audit reports, Confluence review logs, certification records
Professional
13. Compliance
Privacy and data protection
Privacy Act alignment; M365 DLP policies
Data Loss Prevention policies in M365 (Purview); privacy impact assessments for new services; data breach notification process (72hr to OAIC where applicable); data handling aligned to APPs
DLP policy reports, privacy impact assessments, breach notification records
Professional
Gap Analysis
1. Information Security Governance
Coverage: Strong
No significant gaps. ISMS, risk management, and role definitions are well-established. Minor gap: IS18 specifically requires Queensland Government context awareness (e.g., QGISCF alignment) which may need explicit documentation for QLD agency clients.
2. Information Asset Management
Coverage: Strong
Asset inventory and classification are covered. Minor gap: M365 Sensitivity Labels require Purview licensing which may not be available at Essential tier. Essential tier clients may lack automated classification.
3. Human Resource Security
Coverage: Adequate
Screening and training are solid. Gap: IS18 expects security clauses in employment contracts referencing Queensland-specific obligations. Verify that standard employment agreements include IS18-specific language for QLD engagements.
4. Physical Security
Coverage: Partial — Client-Dependent
Netier is an MSP and does not control client physical premises. Physical security is largely a client responsibility. Gap: Netier lacks a formalised physical security assessment checklist specific to IS18 requirements for onboarding new QLD clients. Remote wipe and BitLocker provide compensating controls for endpoint scenarios.
5. Access Control
Coverage: Strong
Entra ID, PIM, Conditional Access, FIDO2, and LAPS provide comprehensive coverage. Gap: Automated access reviews (Entra Access Reviews) are only available at Enterprise tier. Essential and Professional clients rely on manual quarterly reviews which may not meet IS18 frequency expectations for high-privilege accounts.
6. Cryptography
Coverage: Adequate
BitLocker and TLS enforcement are solid. Gap: IS18 may require alignment to ASD-approved cryptographic algorithms (ISM controls). Customer-managed keys (CMK) for M365 data-at-rest encryption are only available at Enterprise tier. No dedicated key management system (e.g., Azure Key Vault or HSM) is documented for lower tiers.
7. Operations Security
Coverage: Strong
Comprehensive vulnerability management, patching, backup, and monitoring. Minor gap: Formal audit trail review process (who reviews logs, how often, what triggers investigation) should be documented more explicitly for IS18 evidence.
8. Communications Security
Coverage: Strong
Email security, network segmentation, DNS filtering, and firewall management are well-covered. Minor gap: Information transfer policies (e.g., secure file transfer, removable media controls) could be more explicitly documented beyond email.
9. System Acquisition & Development
Coverage: Moderate
CIS baselines and pre-deployment scanning provide a foundation. Gap: Netier is primarily an MSP, not a software development house, but IS18 expects secure SDLC practices for any custom tooling or automation developed internally. No formal secure coding standard or code review process is documented. ThreatLocker learning mode is a compensating control but not a substitute for SDLC rigour.
10. Supplier Management
Coverage: Strong
SOC2/ISO27001 requirements, shared responsibility matrix, and data sovereignty tracking are mature. Minor gap: IS18 requires specific attention to data sovereignty within Australia; verify all vendor data processing locations are documented and that no QLD government data transits non-AU jurisdictions without approval.
11. Incident Management
Coverage: Strong
Sophos MDR, Defender, and documented IRP provide solid coverage. Gap: IS18 requires notification to the Queensland Government Chief Information Security Officer (QGCISO) for certain incident categories. This specific escalation path should be documented in the IRP for QLD engagements.
12. Business Continuity
Coverage: Strong
Tiered DRP testing and immutable backups are well-structured. Minor gap: Essential tier only tests DRP annually, which may not meet IS18 expectations for critical systems. Business impact analysis (BIA) methodology should be explicitly documented.
13. Compliance
Coverage: Adequate
Multi-framework alignment is a strength. Gap: IS18 specifically references the Queensland Government Information Security Classification Framework (QGISCF) and requires alignment to it rather than generic sensitivity labels. Privacy obligations under the Information Privacy Act 2009 (Qld) differ from the Commonwealth Privacy Act and should be explicitly addressed.
Recommendations
High Priority
Queensland-Specific IRP Escalation Path
Update the Incident Response Plan to include QGCISO notification requirements, timelines, and contact details for Queensland Government engagements. Map incident severity levels to IS18 reporting obligations.
Physical Security Assessment Checklist
Develop a standardised IS18-aligned physical security assessment template for use during QLD client onboarding. Include facility access controls, environmental protections, equipment disposal, and visitor management. Document Netier's limited scope as MSP and client responsibilities.
QGISCF Alignment for Classification
Map M365 Sensitivity Labels to the Queensland Government Information Security Classification Framework (UNCLASSIFIED, OFFICIAL, OFFICIAL:Sensitive, PROTECTED). Ensure labeling policies, handling procedures, and DLP rules reflect QGISCF requirements specifically, not just generic sensitivity tiers.
| UNOFFICIAL | No label required | None | No restrictions |
| OFFICIAL | OFFICIAL | Internal sharing permitted; external sharing logged | Standard handling; no special controls required |
| OFFICIAL:Sensitive | OFFICIAL:Sensitive | Block external sharing without encryption; alert on bulk download | Encryption enforced for external recipients; sensitivity footer applied |
| PROTECTED | PROTECTED | Block all external sharing; block USB copy; encryption mandatory | Enterprise tier only; double-key encryption; restricted distribution list; data residency in Australia |
Secure Development Lifecycle (SDLC) Policy
Document a lightweight SDLC policy for internal tooling and automation (scripts, integrations, custom dashboards). Include code review requirements, version control, testing, and change management. This does not need to be heavyweight but must demonstrate due diligence.
Queensland Privacy Act Alignment
Supplement existing Privacy Act (Cth) documentation with Information Privacy Act 2009 (Qld) requirements, particularly Information Privacy Principles (IPPs) which differ from Australian Privacy Principles (APPs). Ensure data breach notification processes account for QLD-specific obligations.
Medium Priority
Access Review Automation for Lower Tiers
Investigate cost-effective access review automation for Professional tier (e.g., Power Automate workflows for periodic access certification). Essential tier should at minimum have documented manual review checklists with evidence of completion.
Cryptographic Standards Documentation
Create an explicit cryptographic standards document referencing ASD-approved algorithms and key lengths (ISM controls 0471-0499). Map all encryption implementations (BitLocker, TLS, M365, backup encryption) against these requirements.
Log Review Process Formalisation
Document a formal log review schedule: who reviews security logs, frequency (daily for critical alerts, weekly for trends), escalation criteria, and evidence of review. Currently, monitoring tools exist but the human review process is implicit rather than documented.
Information Transfer Policy
Extend communications security documentation beyond email to cover: secure file transfer mechanisms (e.g., SharePoint sharing policies, OneDrive external sharing restrictions), removable media controls (USB policy via Intune/ThreatLocker), and approved data transfer methods for QLD government data.
Business Impact Analysis Template
Develop a standardised BIA template for QLD engagements that maps system criticality to IS18-expected RTO/RPO targets. Use this to justify DRP testing frequency, particularly for Essential tier clients with critical systems that may need more than annual testing.
Low Priority
Key Management System Evaluation
For Enterprise tier clients handling PROTECTED data, evaluate Azure Key Vault or equivalent for customer-managed key scenarios. Document key lifecycle management (generation, distribution, storage, rotation, destruction).
Vendor Data Sovereignty Register Enhancement
Enhance the existing data sovereignty tracking to include explicit per-vendor, per-service data processing locations with evidence (vendor attestations, data processing agreements). Flag any non-AU data processing for QLD government data.
IS18 Evidence Pack Template
Create a reusable evidence pack template for IS18 compliance audits that maps each control family to specific evidence artifacts, responsible parties, and collection procedures. This reduces audit preparation effort for recurring QLD engagements.
This document should be reviewed and updated at least annually, or when significant changes occur to the Netier technical stack, IS18 standard, or client engagement scope.
Purpose: Comprehensive configuration blueprint for ConnectWise Manage (PSA) to track and enforce all security SLAs defined in the Netier Technical Configuration Framework. Designed to be implementable directly by a CW Manage administrator.
Waiting on vendor patch/response. SLA clock paused.
Awaiting Client
In Progress
6
No
No
Waiting on client approval/access. SLA clock paused.
SLA Clock Pause: Tickets in Awaiting Vendor or Awaiting Client status must be excluded from SLA elapsed time calculations. Configure SLA exclusion under Setup > SLA > Calendar or use the SLA clock pause feature (custom field SLA_Clock_Start can be recalculated on status change via workflow rules).
| Testing / Verification | In Progress | 7 | No | No | Fix applied, verifying resolution |
| Escalated - SLA Risk | In Progress | 8 | Yes | No | SLA threshold breached, escalation active |
| Closed - Exception | Closed | 10 | No | Yes | Risk accepted / compensating control documented |
| Closed - False Positive | Closed | 11 | No | Yes | Finding determined to be non-applicable |
1.3 Types / SubTypes / Items Taxonomy
This taxonomy drives routing, SLA selection, and reporting. Configure under Setup > Service Board > Types.
Type: Patching
SubType
Items
OS - Critical/High
Windows Server, Windows Workstation, Linux, macOS
OS - Standard
Windows Server, Windows Workstation, Linux, macOS
Third-Party Application
Line of Business App, Browser, Runtime/Framework, Utility
Firmware / Driver - Critical
Server BIOS, NIC Firmware, Storage Controller, GPU Driver
Firmware / Driver - Standard
Server BIOS, NIC Firmware, Storage Controller, GPU Driver
Type: Vulnerability Management
SubType
Items
External Scan Finding
Critical, High, Medium, Low, Informational
Internal Scan Finding
Critical, High, Medium, Low, Informational
CISA KEV
Active Exploitation Confirmed, Exploitation Likely
Penetration Test Finding
Critical, High, Medium, Low
Type: Firewall / Perimeter
SubType
Items
Firmware Update
FortiGate, SonicWall, Meraki, pfSense, Other
Critical CVE
FortiGate, SonicWall, Meraki, pfSense, Other
Config Backup Failure
Daily Backup Missed, Retention Gap
Rule Review
Scheduled Review, Change-Triggered Review
Type: Backup / DR
SubType
Items
M365 Backup Failure
Exchange, SharePoint, OneDrive, Teams
Server Backup Failure
Full Image, Incremental, Application-Aware
Immutability Violation
Storage Target Misconfiguration, Retention Policy
DRP Test
Enterprise Quarterly, Professional Bi-Annual, Essential Annual
Backup Verification Failure
Screenshot Test, Boot Test, Restore Test
Type: Incident Response
SubType
Items
Security Incident
Malware, Ransomware, BEC, Phishing Compromise, Unauthorized Access, Data Breach
SOCI Act Reportable
Critical Infrastructure Incident
NDB / OAIC Reportable
Notifiable Data Breach
Post-Incident Review
PIR Scheduled, PIR In Progress, PIR Complete
Type: Training / Awareness
SubType
Items
Phishing Simulation
Monthly Campaign, Remedial Follow-Up
Core Training Module
Quarterly Assignment, Overdue
Failed Simulation
Auto-Enrolled Remedial Training
Type: Compliance / Documentation
SubType
Items
Document Review Due
Policy, Standard, Procedure, Plan, Risk Register
Audit Finding
Internal Audit, External Audit, Client Audit
Certification Milestone
ISO 27001, Essential Eight, SOCI, ISM
2. Priority Matrix
2.1 Priority Definitions
Configure under Setup > Priorities.
Priority
Level
Color
SLA Response
SLA Update
SLA Resolution
Coverage
P1 - Critical
1
Red
15 min
1 hour
4 hours
24/7
P2 - High
2
Orange
30 min
2 hours
8 hours
24/7
P3 - Medium
3
Yellow
2 hours
4 hours
24 hours
Business Hours
P4 - Low
4
Blue
4 hours
8 hours
72 hours
Business Hours
P5 - Scheduled
5
Green
Next Business Day
N/A
Per Schedule (90 day max)
Business Hours
Business Hours Definition: Mon-Fri 08:00-18:00 AEST, excluding Australian public holidays.
P1/P2 Patching Clarification: CVSS 9.0+ vulnerability findings from scanners (Tenable/ConnectSecure) are classified as P1 via WF-006. Critical patch failures from NinjaOne monitoring are classified as P2. Both converge on a 48-hour resolution SLA. The distinction is severity source: scanner-detected active exploitation risk (P1) vs. failed automated patch deployment (P2).
P5 Auto-Escalation: P5 (Scheduled) tickets that remain open beyond 90 days must be automatically escalated to P4 and reassigned. Configure via workflow rule monitoring age of P5 tickets.
2.2 Security SLA to Priority Mapping
This table defines which priority each security SLA category maps to when tickets are created.
Security SLA Category
Default Priority
Justification
Critical/High CVE Patching (48h)
P2 - High
48h resolution window, security-critical
Standard OS Patching (14d)
P4 - Low
14-day window, scheduled maintenance
Third-Party App Patching
Same as OS tier
Mirrors OS SLA per TCF
Firmware / Driver — High Priority (14d)
P3 - Medium
14-day window, requires change control
Firmware/Driver - Standard (30d)
P4 - Low
30-day window, planned maintenance
Firewall Firmware N-1 (30d)
P3 - Medium
30-day window, perimeter device
Firewall Critical CVE (48h)
P1 - Critical
Perimeter device, 48h, actively targeted
Network Config Backup Failure
P3 - Medium
Daily compliance requirement
M365 Backup Failure
P2 - High
3x daily requirement, data loss risk
Server Backup Failure
P2 - High
Daily requirement, RPO breach
Immutability Violation
P1 - Critical
Ransomware resilience control compromised
DRP Test Due
P4 - Low
Scheduled, long lead time
Backup Verification Failure
P3 - Medium
Unverified backup = no backup
External Vuln Scan - Critical
P2 - High
Internet-facing, Critical CVSS
External Vuln Scan - High
P3 - Medium
Internet-facing, High CVSS
Internal Vuln Scan - Critical
P3 - Medium
Internal network, Critical CVSS
Internal Vuln Scan - High
P4 - Low
Internal network, High CVSS
CISA KEV Finding
P1 - Critical
Known active exploitation, immediate action
Security Incident (general)
P1 - Critical
Active threat, business impact
SOCI Act Reportable (12h)
P1 - Critical
12h statutory deadline
NDB/OAIC Reportable (72h)
P1 - Critical
72h statutory deadline
Post-Incident Review (14d)
P3 - Medium
14-day completion window
Phishing Simulation Overdue
P4 - Low
Monthly cadence, training focus
Training Module Overdue
P4 - Low
Quarterly cadence
Failed Phishing - Remedial
P3 - Medium
User is a proven risk vector
Document Review Due
P5 - Scheduled
6-12 month cycle, planned
3. SLA Definitions
Configure under Setup > SLA.
3.1 SLA: Security - Critical (48h)
Field
Value
SLA Name
Security - Critical 48h
Based on
Custom (hours)
Application Order
1
Response Hours
0.5
Response Percent
25%
Plan Hours
2
Plan Percent
50%
Resolution Hours
48
Resolution Percent
100%
Calendar
24/7
Applies To
Type = Patching, SubType = OS - Critical/High; Type = Firewall / Perimeter, SubType = Critical CVE
Expected Priority
P1, P2
3.2 SLA: Security - Standard Patching (14d)
Field
Value
SLA Name
Security - Standard Patch 14d
Based on
Custom (hours)
Resolution Hours
336 (14 days)
Calendar
Business Hours
Applies To
Type = Patching, SubType = OS - Standard, Third-Party Application, Firmware / Driver - Critical
Expected Priority
P3, P4
3.3 SLA: Security - Firmware Standard (30d)
Field
Value
SLA Name
Security - Firmware 30d
Resolution Hours
720 (30 days)
Calendar
Business Hours
Applies To
Type = Patching, SubType = Firmware / Driver - Standard; Type = Firewall / Perimeter, SubType = Firmware Update
Expected Priority
P4
3.4 SLA: Backup - Daily Compliance
Field
Value
SLA Name
Backup - Daily Compliance
Response Hours
0.5
Resolution Hours
8
Calendar
24/7
Applies To
Type = Backup / DR, SubType = Server Backup Failure, M365 Backup Failure
Expected Priority
P2
3.5 SLA: Incident Response - SOCI (12h)
Field
Value
SLA Name
Incident - SOCI 12h
Response Hours
0.25
Resolution Hours
12
Calendar
24/7
Applies To
Type = Incident Response, SubType = SOCI Act Reportable
Expected Priority
P1
3.6 SLA: Incident Response - NDB (72h)
Field
Value
SLA Name
Incident - NDB 72h
Response Hours
0.25
Resolution Hours
72
Calendar
24/7
Applies To
Type = Incident Response, SubType = NDB / OAIC Reportable
Expected Priority
P1
3.7 SLA: Post-Incident Review (14d)
Field
Value
SLA Name
PIR - 14 Day
Resolution Hours
336
Calendar
Business Hours
Applies To
Type = Incident Response, SubType = Post-Incident Review
Expected Priority
P3
3.8 SLA: Vulnerability Scan - CISA KEV
Field
Value
SLA Name
VulnMgmt - CISA KEV Immediate
Response Hours
0.25
Resolution Hours
48
Calendar
24/7
Applies To
Type = Vulnerability Management, SubType = CISA KEV
Per-Priority SLA Targets (priority is set automatically by WF-006 based on CVSS score):
Priority (set by WF-006)
Response
Plan
Resolution
P1 (CVSS 9.0-10.0)
0.25h
0.5h
48h
P2 (CVSS 7.0-8.9)
0.5h
2h
336h (14d)
P3 (CVSS 4.0-6.9)
2h
4h
720h (30d)
P4 (CVSS 0.1-3.9)
4h
8h
2160h (90d)
Configure these as Priority-level entries within the single SLA definition in Setup > SLA > [VulnMgmt - Standard] > Priority tab.
3.10 SLA: General MSP Response
Field
Value
SLA Name
MSP Standard Response
Calendar
Priority-dependent (P1/P2 = 24/7, P3/P4 = Business Hours)
Application Order
99 (catch-all, lowest priority)
Priority
Response
Plan
Resolution
P1
0.25h
1h
4h
P2
0.5h
2h
8h
P3
2h
4h
24h
P4
4h
8h
72h
3.11 SLA Calendar Definitions
Calendar: 24/7
All hours, all days, including holidays
Used for: P1, P2, incident response, SOCI/NDB deadlines
Calendar: Business Hours
Monday-Friday 08:00-18:00 AEST
Excludes: Australian public holidays (maintain holiday list annually)
Used for: P3, P4, P5, standard patching, firmware, training, documentation
4. Workflow Rules
Configure under Setup > Workflow Rules. All rules apply to the Security Operations board unless noted.
SLACK INTEGRATION NOTE: CW Manage workflow rules do not natively support Slack messaging. All Slack notifications in the rules below require one of: (a) Email-to-Slack channel integration (simplest): each Slack channel has an email address — use this as the notification recipient in CW workflow rules (Channel Settings > Integrations > Send emails to this channel) (b) CW Manage Callbacks -> middleware -> Slack Incoming Webhook (via Rewst, Azure Functions, or custom API) (c) Slack integration platform (e.g., Rewst, Gradient MSP)
>
Option (a) requires no middleware and works with native CW email actions. Recommended for initial deployment.
4.1 Auto-Triage on Creation
Field
Value
Rule Name
SEC-WF-001: Auto Triage New Tickets
Board
Security Operations
Trigger
Ticket Created
Condition
Status = New
Actions
Set Status = Triage
Send Email to security-ops@netier.com.au with subject "New Security Ticket: [Ticket#] - [Summary]"
If Priority = P1: Send Slack webhook to #security-alerts
4.2 Auto-Assignment by Type
Field
Value
Rule Name
SEC-WF-002: Auto-Assign by Type
Trigger
Status changes to Triage
Conditions & Actions
Condition (Type)
Assign To (Team/Member)
Patching
Team: Endpoint Engineering
Firewall / Perimeter
Team: Network Engineering
Vulnerability Management
Team: Security Operations
Backup / DR
Team: Infrastructure
Incident Response
Team: Security Operations + notify Security Lead
Training / Awareness
Team: Security Operations
Compliance / Documentation
Team: GRC (Governance, Risk, Compliance) — Note: Verify GRC team exists in CW Manage. If not yet created, use Security Operations as fallback assignment target until GRC team is established.
After assignment, set Status = Assigned.
4.3 SLA Warning Escalation (50% Consumed)
Field
Value
Rule Name
SEC-WF-003: SLA 50% Warning
Trigger
SLA Resolution at 50%
Condition
Status is NOT any Closed type
Actions
Send Email to assigned resource: "SLA WARNING: 50% of resolution time consumed"
Add Internal Note: "AUTOMATED: SLA at 50% - resolution due in [remaining hours]"
If Priority = P1 or P2: Send Slack to #security-alerts
4.4 SLA Escalation (75% Consumed)
Field
Value
Rule Name
SEC-WF-004: SLA 75% Escalation
Trigger
SLA Resolution at 75%
Condition
Status is NOT any Closed type
Actions
Send Email to Team Lead of assigned team
Send Slack to #security-alerts: "ESCALATION: [Ticket#] at 75% SLA"
Set Status = Escalated - SLA Risk
Add Internal Note with current status summary
4.5 SLA Breach (100% Consumed)
Field
Value
Rule Name
SEC-WF-005: SLA Breach
Trigger
SLA Resolution at 100%
Condition
Status is NOT any Closed type
Actions
Send Email to: Security Lead, Service Delivery Manager, assigned resource
Send Slack to #security-alerts AND #leadership: "SLA BREACH: [Ticket#] - [Summary]"
Set Custom Field Statutory Deadline = [calculated datetime]
Implementation Note: CW Manage workflow rules cannot perform datetime arithmetic. The Statutory Deadline custom field must be set via middleware: 1. Configure CW callback on ticket creation for SubType = SOCI Act Reportable or NDB / OAIC Reportable 2. Middleware calculates: Statutory_Deadline = ticket.dateEntered + 12h (SOCI) or + 72h (NDB) 3. PATCH /v4_6_release/apis/3.0/service/tickets/{id} with customFields update
>
Manual Fallback: If middleware is not yet deployed, the triaging analyst must manually calculate and set the Statutory Deadline custom field immediately upon ticket creation.
4.9 Post-Incident Review Auto-Creation
Field
Value
Rule Name
SEC-WF-009: PIR Auto-Create
Implementation Method
CW Manage REST API (via Rewst, Power Automate, or custom middleware)
NOT a native CW workflow rule
CW workflow rules cannot create tickets.
Trigger
Status changes to Resolved
Condition
Type = Incident Response, SubType = Security Incident OR SOCI Act Reportable OR NDB / OAIC Reportable
Actions
Create Child Ticket: Type = Incident Response, SubType = Post-Incident Review, Item = PIR Scheduled
Add Internal Note on parent: "PIR ticket [child#] created. Due within 14 days."
API Implementation
Configure CW Manage Callback: Setup > Integrations > Callbacks. Create a callback that fires on status change to Resolved for tickets matching Type = Incident Response.
Callback hits middleware endpoint: The callback sends ticket data to your middleware (Rewst workflow, Power Automate flow, or custom API endpoint).
Middleware creates child ticket: POST to /v4_6_release/apis/3.0/service/tickets with parentTicketId set to the parent ticket ID to link as a child ticket.
Copy custom fields from parent: Middleware reads the parent ticket's custom fields (Affected Asset Count, Compliance Framework Ref) and includes them in the child ticket payload.
Post internal note on parent: POST to /v4_6_release/apis/3.0/service/tickets/{parentId}/notes with an internal note containing the child ticket reference.
4.10 Failed Phishing Sim - Auto-Enroll Remedial Training
Field
Value
Rule Name
SEC-WF-010: Phishing Fail Remedial
Implementation Method
uSecure API/webhook -> middleware -> CW Manage REST API
NOT a native CW workflow rule
CW workflow rules cannot create tickets from external events. This requires middleware to receive uSecure webhook/API data and create tickets via the CW Manage REST API.
Trigger
Ticket Created
Condition
SubType = Phishing Simulation, Item = anything indicating failure (or Custom Field Simulation Result = Failed)
Actions
Create Child Ticket: Type = Training / Awareness, SubType = Failed Simulation, Item = Auto-Enrolled Remedial Training
Set Priority = P3 - Medium
Assign to Team: Security Operations
Add Internal Note: "User auto-enrolled in remedial training per TCF policy."
4.11 Document Review Reminder (Recurring)
Field
Value
Rule Name
SEC-WF-011: Document Review Reminder
Implementation
Use CW Manage Recurring Tickets (Setup > Service > Recurring)
Frequency
Per document review schedule (6 or 12 months)
Board
Security Operations
Type
Compliance / Documentation
SubType
Document Review Due
Priority
P5 - Scheduled
Assign To
Team: GRC (If not yet created, use Security Operations as fallback.)
Create one recurring ticket template per document category:
Policies: Every 12 months
Standards & Procedures: Every 12 months
Risk Registers: Every 6 months
Incident Response Plans: Every 12 months
BCP/DRP Plans: Every 12 months (aligned with DRP test schedule)
4.12 DRP Test Reminders (Recurring)
Tier
Frequency
Recurring Ticket
Enterprise
Quarterly
Every 3 months, Type = Backup / DR, SubType = DRP Test, Item = Enterprise Quarterly
Professional
Bi-Annual
Every 6 months, Item = Professional Bi-Annual
Essential
Annual
Every 12 months, Item = Essential Annual
4.13 Backup Failure Auto-Close on Success
Field
Value
Rule Name
SEC-WF-013: Backup Recovery Auto-Close
Trigger
Internal Note added (via API from monitoring) containing "BACKUP_SUCCESS_CONFIRMED"
Condition
Type = Backup / DR, Status NOT Closed
Actions
Set Status = Resolved
Add Internal Note: "Backup verified successful by automated monitoring. Auto-closing."
Implementation Note: CW Manage workflow rules cannot trigger on internal note content substring matching. This requires a callback-triggered middleware that parses note content for "BACKUP_SUCCESS_CONFIRMED". Configure a CW Manage callback (Setup > Integrations > Callbacks) on ticket note creation, then have the middleware inspect the note body and update the ticket status via the REST API if the marker string is found.
5. Custom Fields
Configure under Setup > Custom Fields. Apply to the Security Operations board.
NinjaOne Alert UID -> Custom Field NinjaOne_Alert_ID
NinjaOne Device Name -> Ticket Summary prefix + Affected_Assets
NinjaOne Organization -> CW Company (matched by org name or custom mapping table)
CVE ID (if available) -> Custom Field CVE_ID
Deduplication: Check for existing open ticket with same NinjaOne_Alert_ID before creating new ticket. If exists, add Internal Note to existing ticket instead.
API Endpoint (CW Manage REST v4):
POST /v4_6_release/apis/3.0/service/tickets
Sample Payload:
{
"summary": "[PATCH] Critical CVE-2026-XXXXX on SRV-DC01",
Middleware fetches findings via Tenable/ConnectSecure API
Filter: Only Critical and High findings (CVSS >= 7.0) auto-create tickets; Medium/Low go to report only
Dedup: Check existing open tickets by CVE_ID + Company. If exists, update Affected_Asset_Count and add note
Create ticket per unique CVE-per-client (not per-asset, to avoid ticket flood)
Field Mapping:
Scanner Field
CW Field
CVE ID
Custom Field CVE_ID
CVSS v3.1 Score
Custom Field CVSS_Score
CVSS Vector
Custom Field CVSS_Vector
Affected Host Count
Custom Field Affected_Asset_Count
Affected Hostnames
Custom Field Affected_Assets
Scanner Name
Custom Field Scan_Source
Plugin/Finding Name
Ticket Summary
Solution/Remediation
Ticket Initial Description (internal note)
CISA KEV Check: Middleware cross-references each CVE against the CISA KEV catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog). If match found:
Set SubType = CISA KEV
Triggers WF-007 (immediate escalation)
7.3 Veeam -> CW Manage (Backup Monitoring)
Integration Method:
Veeam: Veeam Service Provider Console (VSPC) integration or Veeam ONE alerts -> CW Manage via API/email connector
Alert-to-Ticket Mapping:
Backup Alert
CW Ticket
Backup Job Failed
Type: Backup / DR, SubType: Server Backup Failure, Priority: P2
Backup Job Warning (partial)
Type: Backup / DR, SubType: Server Backup Failure, Priority: P3
Type: Backup / DR, SubType: Server Backup Failure, Priority: P2
Auto-Resolution: When backup monitoring detects the next successful backup:
API call to update ticket with Internal Note "BACKUP_SUCCESS_CONFIRMED"
WF-013 triggers auto-close
M365 Backup (3x Daily): If any of the 3 daily backup windows fails, create ticket. Only auto-close if a subsequent window succeeds within the same day.
Implementation Note: The following workflow rules require middleware or external API integration and cannot be implemented as native CW Manage workflow rules alone:
>
| Rule | Requirement | Recommended Approach | |------|------------|---------------------| | WF-008 (Statutory Timer) | Calculate datetime for Statutory_Deadline field | Rewst workflow or custom API script triggered on ticket creation | | WF-009 (PIR Auto-Create) | Create child ticket on parent resolution | CW Manage callback -> middleware -> CW Manage REST API (workflow rules cannot create tickets) | | WF-010 (Phishing Remedial) | Create ticket from phishing simulation results | uSecure API/webhook -> middleware -> CW Manage REST API | | WF-013 (Backup Auto-Close) | Detect backup success and add internal note | Monitoring platform API -> CW Manage internal note API | | All Slack notifications | Send messages to Slack channels | Email-to-Slack, Rewst, or custom webhook relay |
>
Recommended middleware platform: Rewst (MSP-focused integration platform with native CW Manage and NinjaOne connectors).
7.7 Integration Architecture Summary
NinjaOne ──────────┐
Tenable/ConnectSecure ──┤
Veeam ──────────────┤ ┌─────────────────────┐
ThreatLocker ───────┼────>│ Integration Layer │────> CW Manage REST API
Sophos MDR ─────────┤ │ (Rewst / Custom) │ |
uSecure ────────────┤ │ │ Security Operations
CISA KEV Feed ──────┘ │ - Dedup logic │ Board
│ - Field mapping │ |
│ - CISA KEV cross-ref│ Workflow Rules
│ - Company matching │ |
└─────────────────────┘ SLA Engine
|
Escalation &
Notifications
(Email + Slack)
8. Implementation Checklist
Phase 1: Foundation (Week 1-2)
☐ Create Security Operations service board
☐ Configure all statuses per Section 1.2
☐ Create Types / SubTypes / Items per Section 1.3
☐ Define priorities per Section 2.1 (if not already existing)
☐ Create SLA calendars: 24/7 and Business Hours (with holiday list)
☐ Create all SLA definitions per Section 3
☐ Create all custom fields per Section 5
Phase 2: Workflow Rules (Week 2-3)
☐ Implement WF-001 through WF-005 (triage, assignment, SLA escalation chain)
☐ Implement WF-006 and WF-007 (CVSS priority mapping, CISA KEV)
☐ Implement WF-008 and WF-009 (statutory notification, PIR auto-create)
☐ Implement WF-010 (phishing fail remedial)
☐ Configure recurring tickets per WF-011 and WF-012 (document review, DRP tests)
☐ Implement WF-013 (backup auto-close)
☐ Configure Slack webhook integration for #security-alerts and #leadership channels
Netier is an Australian Managed Service Provider (MSP) headquartered in Canberra, ACT. The company provides managed IT infrastructure, security operations, and compliance management services to approximately 30 clients across government, defence, critical infrastructure, and private sector verticals.
Sophos Central — MDR, endpoint protection, email gateway
Microsoft 365 — Internal and client tenant management via delegated admin (GDAP)
Veeam — Backup orchestration across client environments
Netier Compliance Engine — Custom ISM compliance scanning tool (web security, email auth, DNS controls)
CyberCred — Security Champions gamification platform (cyber.netier.team) — points-based incentive system for security awareness, training completion, and proactive security behaviours
ISMS Scope & Boundaries
Scope covers the delivery of managed IT and security services to external clients
Includes internal IT systems used for service delivery (RMM, ITSM, monitoring)
Client environments are managed under the ISMS but client-owned assets remain under client risk ownership
Physical scope includes Netier office premises and remote worker endpoints
Key risk: As an MSP, compromise of Netier's management tools (NinjaOne, CW, M365 GDAP) would cascade to all managed clients
Risk appetite: Low tolerance for security incidents affecting client data; moderate tolerance for operational disruptions with defined recovery objectives
Critical infrastructure note: Canberra Airport (CAG) is a designated critical infrastructure asset under the SOCI Act 2018. Netier manages CAGSEC domain infrastructure including Gallagher access control, CCTV, and corporate IT systems.
SoA evidence decay identified (Sept 2023 dates); relies heavily on generic policies
ISO 27002:2022
3
80% (Implicit)
Missing formal attribute tagging and continuous measurement
ASD ISM (Dec 2025)
2
60% (Partial)
Technical alignment strong; maturity 2 reflects gap in formal policy/process documentation despite strong technical controls. Major gaps in new controls (AI, CBOM, Auth)
ASD Essential Eight
4
75% (ML1/ML2)
Strong on App Control/MFA; ML3 gaps in centralized logging & 48hr SLAs
Purpose: Pre-identified gaps that Netier is already aware of. Provided so the reviewer can focus on unknown gaps, quality issues, and cross-framework coverage rather than restating these known deficiencies.
>
Last Updated: 2026-03-24 Total Gaps: 24 | Cross-referenced to: remediation-tracker.csv (REM-01 to REM-26)
Critical Gaps (Must-Fix)
GAP-01: AI Governance — No Formal Policy
Frameworks: ISM Dec 2025 (ISM-AI-01, ISM-AI-02)
Status: Non-Conforming
Progress: Not Started | REM: REM-06
Detail: No documented AI usage policy, no model/system cards, no AI risk assessment framework. AI tools (Claude, Copilot) are in use internally and being deployed on client endpoints (evidenced by ThreatLocker approval requests).
Remediation: Draft AI Usage Policy, create system card templates, establish AI tool approval process. Target: Q2 2026.
GAP-02: Cryptographic Bill of Materials (CBOM)
Frameworks: ISM Dec 2025 (ISM-CBOM-01)
Status: Non-Conforming
Progress: Not Started | REM: REM-07
Detail: No CBOM process exists. Software inventory tracked in NinjaOne but without cryptographic dependency analysis. No scanning for deprecated crypto algorithms.
Detail: Canberra Airport is a designated critical infrastructure asset. Netier manages IT infrastructure but no formal CIRMP has been documented. Mandatory incident reporting obligations (12hr/72hr) not formally integrated into incident response procedures.
Remediation: Engage with CAG management to establish CIRMP. Map existing controls to SOCI requirements. Integrate SOCI reporting into IR playbooks. Target: Q2 2026. Note: May require legal input.
GAP-04: Privileged Access Management — PIM Live at CAG, PAWs Pending
Frameworks: E8 ML2-ML3 (E8-RAP), ISM, NIST CSF, CIS Control 6
Status: In Progress (PIM deployed at CAG)
Progress: In Progress | REM: REM-08
Detail: Azure AD PIM is live at CAG — CW #1752374 "MFA Setup PIM Accounts" (March 2026), #1752093 "CAG PIM Account - Nathan Sole" (March 2026), weekly PIM digests received (#1754981). Gap: PIM not rolled out beyond CAG to other managed tenants. No Privileged Access Workstations deployed for Tier 0 administration.
Remediation: Extend PIM rollout from CAG to all managed tenants. Establish PAW program for DC/AAD/security tool administration. Target: Q3 2026.
High Gaps (Should-Fix Within 6 Months)
GAP-05: PSPF — Not Formally Mapped
Frameworks: PSPF (all 4 pillars)
Status: Not Assessed
Progress: Not Started | REM: REM-22
Detail: Federal government clients require PSPF compliance. Netier has not formally mapped its controls to PSPF mandatory requirements. Some overlap exists via ISO 27001 and ISM alignment.
Detail: PII handled across all clients but no formal Privacy Impact Assessment process. NDB scheme breach reporting not formally integrated into incident response. No documented data flow mapping for PII.
Remediation: Establish PIA process, map PII data flows per client, integrate NDB reporting into IR playbooks. Target: Q3 2026.
GAP-07: Security Awareness Training — No Formal Platform
Frameworks: ISO A.6.3, ISM, IS18 Policy Requirement 4 (IS18-AWARE-01 downgraded to OFI), NIST CSF PR.AT, CIS Control 14
Status: Gap (IS18-AWARE-01 status corrected from Conforming to Opportunity for Improvement)
Progress: Not Started | REM: REM-12
Detail: uSecure procured as security awareness training platform. Phishing simulation testing not yet operational. Onboarding includes MFA setup guides but no structured security induction.
Remediation: Evaluate and procure SAT platform, implement quarterly phishing simulations, document security induction process. Target: Q2 2026.
Frameworks: E8 ML3 (E8-MFA), ISM Dec 2025 (ISM-AUTH-01)
Status: Conforming at ML2, In Progress at ML3
Progress: In Progress | REM: REM-09
Detail: FIDO2 keys actively deployed to staff — not just pilot. CW evidence: broken key (#1746812), PIN issues (#1745815), sign-in errors (#1714723), key-at-home (#1735004), NinjaOne FIDO compatibility (#1748363). Confluence KB: netier.atlassian.net/wiki/spaces/STS/FIDO2. Gap: not universal across all clients/users. Most non-admin users still on push MFA.
Remediation: Expand FIDO2 to all admin accounts across all clients, then all users for ML3 clients. Track via Netier Compliance Engine Phase 3. Target: Q3 2026.
GAP-09: DR Testing — Not Regular Across All Clients
Detail: Backups performed and monitored (Veeam + NinjaOne) but full environment restoration testing not performed regularly. DR restoration SLAs not formally documented per client.
Remediation: Implement quarterly full restoration test schedule, document DR SLAs in client agreements. Target: Q2 2026.
GAP-10: DISP Obligations — Partially Documented
Frameworks: DISP (all pillars)
Status: Partially Conforming
Progress: Not Started | REM: REM-26
Detail: H1R clearance evidence held. DISP membership obligations exist but formal mapping of all security obligations (personnel, physical, ICT, supply chain) not completed.
Medium Gaps (Nice-to-Have / Continuous Improvement)
GAP-11: Risk Quantification — No Formal Methodology
Frameworks: ISO 27005, NIST CSF GV, IS18 Policy Requirement 2
Status: Gap
Progress: Not Started | REM: REM-25
Detail: Security risks managed qualitatively per-client but no standardised risk quantification methodology (FAIR, ISO 27005). No unified corporate risk register at Netier level.
Remediation: Evaluate FAIR or ISO 27005, establish unified risk register template. Target: Q4 2026.
GAP-12: APRA CPS 234 — Not Formally Assessed
Frameworks: APRA CPS 234
Status: Not Assessed
Progress: Not Started | REM: REM-23
Detail: Financial sector clients subject to APRA regulation. Netier has not formally mapped controls to CPS 234 requirements. Existing ISO 27001 controls likely cover significant portion.
Remediation: Perform CPS 234 gap analysis against existing ISO 27001 controls. Target: Q4 2026.
GAP-13: PCI DSS v4.0 — Not Formally Assessed
Frameworks: PCI DSS v4.0
Status: Not Assessed
Progress: Not Started | REM: REM-24
Detail: Clients handling payment card data require PCI DSS compliance. Scope and applicability not formally determined. Network segmentation of cardholder data environments not verified.
Remediation: Identify clients in PCI scope, determine SAQ level, perform gap analysis. Target: Q4 2026.
GAP-14: IS18 Annual Return — No Standardised Process
Frameworks: IS18 Policy Requirement 5
Status: Opportunity for Improvement
Progress: Not Started | REM: REM-19
Detail: 169-requirement annual return checklist not mapped to current tooling. Evidence collection not automated. Annual return process depends on manual effort.
Remediation: Obtain IS18 annual return template, map to evidence sources, automate where possible. Target: September 2026 (aligned with annual deadline).
GAP-15: SSPR Security Questions — ISM Prohibited Authentication
Frameworks: ISM Dec 2025 (ISM-AUTH-01)
Status: Opportunity for Improvement
Progress: Not Started | REM: REM-15
Detail: Some M365 tenants may still permit security questions as SSPR verification method, which ISM explicitly prohibits. Email-based OTP may also be permitted in legacy conditional access policies.
Remediation: Audit all managed tenants, disable security questions in SSPR, remove email OTP from permitted methods. Target: Q2 2026.
Systemic Findings (Gemini R2)
GAP-16: SoA Evidence Decay
Frameworks: ISO 27001
Status: Gap
Progress: In Progress (CSV generated, not yet applied to XLSX) | REM: REM-01
Detail: The baseline Statement of Applicability relies on circular logic (generic policy names) and has suffered from severe evidence decay (last reviewed September 2023).
Remediation: Rewrite SoA evidence column to reference specific, verifiable technical artifacts (e.g. CW Ticket #1755124, Intune policies). Target: Q2 2026.
GAP-17: Asset Discovery Blindspot
Frameworks: CIS 1.1, SOCI
Status: Gap
Progress: Not Started | REM: REM-02
Detail: Passive asset management means attackers can map internal subnets unseen by NinjaOne. No active network discovery tool deployed to catch unmanaged/IoT/OT devices.
Detail: No SIEM deployed. ThreatLocker blocks and Entra ID failed logins are not correlated centrally, inhibiting proactive threat hunting and MTTD tracking.
Progress: In Progress (CSV generated) | REM: REM-03
Detail: No clear delineation of Netier-managed vs Client-owned controls in documentation. Essential for regulatory audits like CPS 234 and PCI.
Remediation: Develop and attach shared responsibility matrix to MSAs. Target: Q2 2026.
GAP-20: Incident Reporting Timeline Collision
Frameworks: SOCI, APRA, NDB
Status: Gap
Progress: In Progress (CSV generated) | REM: REM-04
Detail: Multiple statutory reporting timelines (12hr/20hr/72hr/30d) exist without a unified incident triage matrix, creating risk of a statutory breach during an incident.
Remediation: Update IR playbook with a unified reporting matrix. Target: Q2 2026.
GAP-21: Data Sovereignty vs SaaS
Frameworks: PSPF, DISP
Status: Gap
Progress: In Progress (awareness exists) | REM: REM-14
Detail: Key managed tools (NinjaOne, ThreatLocker) are US-based and process Australian metadata. Not formally assessed against government/defence data sovereignty requirements.
Remediation: Assess legal sovereignty risk for NinjaOne/ThreatLocker. Target: Q3 2026.
GAP-22: No Explicit DLP
Frameworks: ATT&CK (Exfiltration)
Status: Gap
Progress: Not Started | REM: REM-16
Detail: No explicit Data Loss Prevention deployed. Missing protections against mass exfiltration to unauthorized cloud storage.
Remediation: Evaluate and deploy Microsoft Purview DLP. Target: Q4 2026.
GAP-23: No FIM Capability
Frameworks: ATT&CK (Persistence)
Status: Gap
Progress: Not Started | REM: REM-17
Detail: File Integrity Monitoring is lacking, making silent persistence by attackers possible despite baseline hardening.
Remediation: Deploy FIM capabilities via Sophos or SIEM. Target: Q4 2026.
GAP-24: Supply Chain Concentration Risk
Frameworks: CSF-GV, SOCI
Status: Gap
Progress: Not Started | REM: REM-18
Detail: Complete reliance on 'Big 4' vendors (Microsoft, Sophos, NinjaOne, ThreatLocker). Systemic risk if one is compromised.
Remediation: Perform formal ISO 27036 risk assessment on top 4 vendors. Target: Q3 2026.
Subject: [Client Name] — Discovery Audit Findings and Recommended Next Steps
Good morning [Name],
Thank you for engaging Netier to conduct the Phase 1 Discovery Audit of your environment. I wanted to share our initial findings with you directly, as several items require urgent attention.
During the audit, we identified a number of critical and high-severity risks across your infrastructure. The following is a summary of the most significant issues:
IDENTITY AND ACCESS MANAGEMENT
[MFA STATUS: e.g., "Multi-factor authentication is not enforced on privileged administrator accounts" OR "MFA is enforced for administrators but not standard users" OR "MFA is enforced universally — no finding."]
[SERVICE ACCOUNTS: e.g., "[X] service accounts with domain admin privileges have passwords that have not been rotated in over [X] months."]
[CA POLICIES: e.g., "Conditional Access policies are either absent or not enforced" OR "Conditional Access policies are configured but do not include device compliance requirements."]
PATCH MANAGEMENT AND VULNERABILITY EXPOSURE
[CRITICAL CVES: e.g., "[X] critical CVEs across the server fleet are older than 90 days and remain unpatched with known public exploits" OR "Patching is current for servers but [X] workstations have critical patches outstanding."]
[EOL SYSTEMS: e.g., "End-of-life operating systems (Windows Server 2012 R2 / Windows 10 21H2) are still in production with no extended security update coverage" OR "All operating systems are within support lifecycle — no finding."]
[FIRMWARE: e.g., "Firmware on the perimeter firewall ([Make/Model]) is [X] major versions behind the current release and contains known remote code execution vulnerabilities" OR "Firewall firmware is current — no finding."]
ENDPOINT AND APPLICATION SECURITY
[APP CONTROL: e.g., "No application whitelisting or control solution is deployed" OR "Application control is deployed but not enforced in block mode" OR "Application control is fully enforced — no finding."]
[EDR COVERAGE: e.g., "Endpoint detection and response (EDR) coverage is incomplete — approximately [X]% of endpoints have no active protection agent" OR "EDR is deployed to all endpoints — no finding."]
BACKUP AND RECOVERY
[BACKUP STATUS: e.g., "Backup jobs for [X] critical systems have been failing for [X] days with no alerting or remediation in place" OR "Backups are completing successfully but have never been tested for restore integrity."]
[RECOVERY TESTING: e.g., "There is no evidence of backup integrity testing or documented recovery procedures" OR "Recovery testing is documented but last performed over 12 months ago."]
REGULATORY AND BUSINESS IMPACT
These findings carry significant regulatory exposure. Under the Privacy Act 1988 (Notifiable Data Breaches scheme), your organisation would be required to notify the OAIC and affected individuals in the event of a breach involving personal information. The absence of basic controls such as MFA and patching materially increases the likelihood of such an event.
If your organisation falls within the scope of the Security of Critical Infrastructure Act 2018 (Cth) (as amended), additional reporting obligations and potential government intervention powers apply.
From a business continuity perspective, the current state of the environment presents a realistic risk of a ransomware event resulting in extended operational downtime, data loss, and reputational damage. Cyber insurance coverage may also be jeopardised, as most insurers now require evidence of MFA, EDR, and patching as minimum conditions.
NEXT STEPS
We need to discuss remediation options before we can proceed to the managed service engagement. Netier's onboarding model requires that critical risks are addressed during Phase 1 (Remediation) before we can transition your environment into our managed service platform. This is not a commercial preference — it is a risk management requirement that protects both organisations.
I would like to schedule a call this week to walk through these findings in detail and discuss the remediation pathway. Please let me know your availability.
Following our discussion of the Discovery Audit findings, I am pleased to present Netier's Phase 1 Remediation Proposal for [Client Name].
CONTEXT
During the Discovery Audit, your environment received a Compliance Readiness Score of [X]/100. This score reflects your current alignment against the ASD Essential Eight, ISO 27001 Annex A controls, and baseline security requirements that Netier mandates for all managed service clients.
For reference, Netier requires a minimum score of [X]/100 before an environment can be transitioned into Phase 2 (Managed Service). Your current score of [X]/100 indicates that mandatory remediation is required before onboarding can proceed.
This is not optional. Netier cannot accept operational responsibility for an environment with unresolved critical vulnerabilities, as doing so would expose both your organisation and Netier to unacceptable risk. The remediation phase is a contractual prerequisite to the managed service engagement.
REMEDIATION SCOPE
The following table summarises the remediation work required to bring your environment to the minimum baseline:
Item | Description | Est. Cost
R-01 | [e.g., Deploy and enforce MFA across | $[X,XXX]
R-06 | [e.g., Privileged access review and | $[X,XXX]
| service account hardening] |
R-07 | [e.g., EDR deployment to uncovered | $[X,XXX]
| endpoints via Sophos] |
| TOTAL PHASE 1 REMEDIATION | $[XX,XXX]
Phase 1 is scoped for completion within 30 days from approval. All work is performed by Netier engineers using our standard tooling (NinjaOne, Intune, ThreatLocker, Sophos, Veeam) to ensure a clean handover into the managed service.
INVESTMENT CONTEXT
I want to be clear about why this investment matters beyond the immediate security benefit.
Completing Phase 1 remediation is the gateway to Netier's Co-Investment program under Phase 2. Once your environment meets our baseline, Netier will absorb the upfront transformation costs of onboarding you into our fully managed platform and amortize those costs over the 3-year agreement term. This includes deployment of our full monitoring, automation, and compliance stack at no additional upfront cost to you.
[CO-INVESTMENT TIER: Refer to the current Amortized Transformation pricing model for co-investment eligibility based on seat count. Confirm tier with Service Delivery Manager before sending.]
The Phase 1 remediation cost is a one-time investment. It is not amortized and is payable on commencement. Think of it as the entry ticket to a fundamentally different level of managed service — one where you receive all-you-can-eat support, proactive security operations, and compliance alignment as standard inclusions.
NEXT STEPS
Please review the attached scope and confirm your approval so we can schedule the remediation sprint. If you have questions about any line item, I am happy to walk through the detail.
The sooner we begin, the sooner your environment reaches the baseline required for Phase 2 onboarding.
Thank you for the time you and your team have invested in discussions with Netier over recent weeks. I want to be straightforward with you about where we have landed.
Following completion of our Phase 1 Discovery Audit and subsequent discussions regarding remediation, Netier has made the decision to exercise our Right to Refuse under the proposed engagement terms. We will not be proceeding with onboarding [Client Name] into our managed service platform at this time.
I want to explain the reasoning behind this decision clearly and respectfully.
WHY WE ARE DECLINING
During the Discovery Audit, we identified critical security deficiencies across your environment — including but not limited to the absence of multi-factor authentication on privileged accounts, unpatched critical vulnerabilities with known active exploits, and the lack of fundamental endpoint protection and application control.
We presented a remediation proposal to address these issues as a prerequisite to onboarding. That proposal was declined.
Netier's managed service model is built on the principle that we accept operational responsibility for our clients' environments. That responsibility includes accountability for security posture, compliance alignment, and incident outcomes. We cannot accept that responsibility for an environment with known critical vulnerabilities that remain unaddressed by choice.
Onboarding [Client Name] in its current state would expose your organisation to continued and material risk of a significant security incident, including ransomware, data exfiltration, and regulatory action under the Privacy Act 1988 and potentially the Security of Critical Infrastructure Act 2018 (Cth) (as amended). It would also expose Netier to liability that we are not prepared to accept.
This is not a reflection of the value we place on the relationship. It is a risk management decision that we apply consistently to all prospective clients.
WHAT THIS MEANS
Netier will not proceed with a managed service agreement for [Client Name] under current conditions.
Any Discovery Audit deliverables (reports, findings, scorecards) that have been provided to you remain your property and can be used with any provider.
We will securely destroy any copies of your environment data held by Netier within 30 days, in accordance with our data handling policy.
THE DOOR REMAINS OPEN
Should your organisation's position on remediation change in the future, we would genuinely welcome the opportunity to reassess. The Discovery findings and remediation scope we prepared would serve as a strong starting point for that conversation, though a re-validation of the environment would be required given the passage of time.
You are welcome to contact me directly at any point to revisit this.
I wish you and your team the best, and I hope we have the opportunity to work together in the future under the right conditions.
Kind regards,
Template 4 — Phase 2 Transition Confirmation
Use when: Phase 1 remediation is complete. Client environment meets minimum Compliance Readiness Score. Managed service agreement is signed.
Subject: Phase 1 Complete — Welcome to Netier Managed Security Services
Dear [CLIENT CONTACT NAME],
I'm pleased to confirm that [CLIENT ORGANISATION] has successfully completed Phase 1 — Security Foundation Remediation.
Phase 1 Summary:
Your environment has been brought to our minimum operational baseline:
[LIST COMPLETED REMEDIATION ITEMS: e.g., "MFA enforced for all users via Conditional Access", "Endpoint protection deployed to 100% of devices via ThreatLocker and Sophos MDR", "Patch management automated via NinjaOne with 48-hour critical patching SLA"]
Your updated Compliance Readiness Score is [X]/100 (up from [X]/100 at Discovery).
Your Managed Service:
Effective [START DATE], your environment is now under active management:
Overall Verdict: CONDITIONAL PASSFULL PASS — All Critical and High Items Resolved (2026-03-26)
Document
Rating
Critical
High
Medium
Low
Remediated
SOP — Identity, CA & Cloud Workspaces
AMBERGREEN
3 0
3 0
2
2
2026-03-26
IS18 Compliance Mapping
GREEN
0
2 0
2 1
1
2026-03-26
Right-to-Refuse Email Templates
GREEN
0
2 0
2 1
1 0
2026-03-26
CW Manage SLA Workflows
REDGREEN
5 0
3 0
2
1 0
2026-03-26
Cross-Document Inconsistencies
REDGREEN
2 0
0
0
0
2026-03-26
TOTAL (original)
10
10
8
5
TOTAL (post-remediation)
0
0
6
3
20/20 resolved
What's Genuinely Good
Before the critique: these documents are substantially better than what most $300/hr consultants produce. Specifically:
SOP — Identity, CA & Cloud Workspaces: This is the standout document. Every CA policy has step-by-step portal navigation, a PowerShell alternative, verification checks, AND rollback procedures. The break glass section gets the sequencing right (create BG accounts BEFORE deploying CA policies). The PIM section correctly separates eligible from active assignments and mandates adm- prefix admin accounts. The Master Verification Checklist at the end is exactly what an engineer needs for tenant sign-off. If the critical items below are fixed, this SOP is deployable to a client-facing tenant tomorrow.
IS18 Compliance Mapping: The 37-control mapping with tier availability is well-structured and the gap analysis is honest — it correctly identifies Physical Security as "Partial — Client-Dependent" (which is the truth for any MSP) rather than pretending it's fully covered. The Queensland-specific recommendations (QGISCF alignment, IPP vs APP differences, QGCISO notification) show genuine IS18 familiarity rather than generic ISO padding.
Email Templates: The commercial language is strong. Template 3 (Walk-Away) strikes exactly the right tone — firm, professional, and leaves the door open. The "co-investment" framing in Template 2 avoids the "paying for the privilege of being managed" trap that sinks most MSP proposals. The plain-text formatting and "Kind regards," closing match Netier's email standards.
CW Manage SLA Workflows: The Type/SubType/Items taxonomy is well-designed and the 13 workflow rules demonstrate genuine understanding of security operations workflows. The integration architecture section with API payload examples and deduplication logic goes well beyond what most PSA configuration docs include. HOWEVER, this document has the most critical issues — several "workflow rules" are described that CW Manage cannot actually implement as workflow rules, which would cause an engineer to hit a wall during implementation.
C1-SOP: Phishing-Resistant MFA Policy Will Lock Out All Users During Initial Deployment
What's wrong: Section "Require MFA for All Users" (lines 369-445) creates a CA policy requiring "Phishing-resistant MFA" authentication strength (FIDO2 or Windows Hello only). The auth methods section (line 386) says to enable Microsoft Authenticator "as fallback during transition." But the CA policy's authentication strength of "Phishing-resistant MFA" explicitly BLOCKS Microsoft Authenticator — it only accepts FIDO2 and Windows Hello for Business. These two instructions contradict each other.
Why it matters: If an engineer follows this SOP on a live tenant, the CA policy will enforce phishing-resistant MFA, but zero users will have FIDO2 keys registered yet. Every user (including admins) gets locked out on enforcement day. The 7-day Report-only period will flag this, but the SOP doesn't explain what to do about it — it implies Authenticator is a valid fallback when the policy explicitly prevents it.
Exact fix: Add a two-phase deployment approach:
### Deployment Phases
Phase A — Transitional (Weeks 1-4):
Deploy CA policy using standard "Require multifactor authentication" grant control
(accepts Authenticator, SMS, voice as well as FIDO2/WHfB). This gets MFA enforced
immediately while FIDO2 keys are distributed.
Phase B — Hardened (Week 5+):
Once >95% of users have registered FIDO2 or WHfB (verify via Authentication Methods
Activity report in Entra Admin Center > Protection > Authentication methods > Activity),
update the CA policy grant control to "Require authentication strength > Phishing-resistant MFA".
Monitor Report-only for 7 days, then enforce.
NOTE: During Phase A, the tenant IS protected by MFA but is vulnerable to MFA fatigue
and SIM-swap attacks. Phase B eliminates these vectors. Do not skip Phase A — a lockout
is worse than a temporary period of non-phishing-resistant MFA.
C2-SOP: PowerShell Break Glass Password Is Not Cryptographically Secure
What's wrong: Line 73: Password = (New-Guid).Guid + "!Aa1". This generates a password like a1b2c3d4-e5f6-7890-abcd-ef1234567890!Aa1.
Why it matters: GUIDs (v4) use a CSPRNG internally but are NOT designed as secrets — they have predictable structure (fixed bits at positions 13 and 17-18), reducing effective entropy. More importantly, the comment says "Replace with securely generated password" but the code runs as-is. A junior engineer will copy-paste this without reading the comment. In an audit, this password generation method would be flagged.
Exact fix: Replace the password generation block (lines 72-75):
Remove the comment "Replace with securely generated password" — the code should be correct as shipped.
C3-SOP: Master Checklist Says "6 Policies Total" but 7 Policies Are Defined
What's wrong: Line 1160: "Conditional Access Policies (6 policies total)" — but the checklist that follows lists 7 distinct policies (Block Legacy Auth, Block Non-AU, Require Compliant Device, Require MFA, Block High Sign-in Risk, MFA for Medium Sign-in Risk, Require Password Change for High User Risk).
Why it matters: An engineer using this checklist for sign-off will count 7 policies and wonder if they built one too many, or if the "6" means the Sign-in Risk block and MFA should be combined. During an ISO audit, a discrepancy between the SOP and the implementation creates a finding.
H1-SOP: Deprecated Microsoft Graph Cmdlet for Role Assignment
What's wrong: Line 87: New-MgDirectoryRoleMember -DirectoryRoleId $roleId -DirectoryObjectId $user.Id
Why it matters:New-MgDirectoryRoleMember targets the legacy Directory Roles API. Microsoft Graph SDK v2+ uses New-MgRoleManagementDirectoryRoleAssignment. The old cmdlet may work on some SDK versions but will fail on fresh installs of Microsoft.Graph v2.x and produces deprecation warnings that confuse engineers.
What's wrong: The User Risk policy (lines 556-630) requires password change and MFA but does not include session controls. Compare with the Sign-in Risk policy (line 482) which sets SignInFrequency.FrequencyInterval = "everyTime".
Why it matters: A user flagged as high-risk who ALREADY has an authenticated session continues accessing resources until their token expires (default: up to 1 hour for access tokens, up to 90 days for refresh tokens). The password change only triggers on next sign-in. During a credential compromise, the attacker's existing session remains valid.
Exact fix: Add session controls to the User Risk policy PowerShell block (after the GrantControls section, before the closing }):
- This forces re-authentication, which triggers the password change requirement for existing sessions
H3-SOP: No Guidance on Service Account and App Registration Exclusions
What's wrong: The MFA policy (line 439) mentions "Service accounts/app registrations that cannot perform MFA are handled (exclude or use managed identity)" as a verification check, but there is NO procedure in the SOP body for handling this.
Why it matters: Every real tenant has service accounts (backup service accounts, line-of-business app registrations, SMTP relay accounts). The MFA policy targets "All users" with no guidance on how to handle these. An engineer will either exclude them insecurely (over-broad exclusion group) or break them (MFA prompt on a headless account).
Exact fix: Add a new sub-section after the MFA policy:
#### Handling Service Accounts and App Registrations
Identify all service accounts and app registrations via:
- Entra sign-in logs filtered to "Service Principal" sign-ins
- Known service accounts (backup, SMTP relay, LOB integrations)
For each, determine the correct approach:
a. Managed Identity (preferred): Migrate to Managed Identity where possible
(Azure-hosted services). Managed Identities are excluded from CA by default.
b. Workload Identity (app registrations): Create a separate CA policy targeting
"Workload identities" with appropriate controls (IP restriction, no legacy auth).
c. Service account exclusion (last resort): Add to a dedicated security group
SG-CA-ServiceAccounts. Exclude this group from the MFA policy ONLY.
Compensating controls: restrict sign-in to Netier management IPs only,
disable interactive logon, monitor via sign-in alerts.
Document every exclusion in a Service Account Register with: account name,
purpose, owner, exclusion justification, compensating controls, and review date.
Medium (fix before next review cycle)
M1-SOP: Teams App ID May Cause Incomplete Coverage
What's wrong: The Compliant Device PowerShell (line 339) targets Teams by App ID cc15fd57-2c6c-4117-a88c-83b1d56b4bbe. This is the Teams client service principal.
Why it matters: Teams accesses data through Exchange Online and SharePoint Online APIs. Targeting the Teams app ID may not catch all data access paths. Microsoft's recommendation is to target the "Office 365" meta-application or rely on the Exchange/SharePoint targeting (which already covers Teams' backend data access).
Exact fix: Add a note in the PowerShell:
# NOTE: Targeting Exchange Online and SharePoint Online already covers
most Teams data access. The explicit Teams app ID is included for
Teams-specific features (chat, calls) that don't route through EXO/SPO.
Alternative: replace all three with the Office 365 meta-app:
IncludeApplications = @("Office365")
M2-SOP: Entra ID Access Reviews Not Covered
What's wrong: The IS18 Compliance Mapping claims "Automated access reviews for privileged roles (monthly)" as a control (line 30), but the SOP contains no procedure for configuring Entra ID Access Reviews.
Why it matters: During an IS18 audit, the assessor will ask for evidence of access reviews. The IS18 mapping points to Entra Access Reviews, but no SOP exists to configure them. The control is claimed but not implementable from this document set.
Exact fix: Add an Access Reviews section to the SOP (after PIM), or create a separate SOP. Minimum content: create recurring access review for Global Admin role, configure monthly cadence, set auto-apply for non-respondents (remove access), assign reviewers.
Low (polish items)
L1-SOP: Break Glass .onmicrosoft.com Guidance Is Debatable
What's wrong: Line 39: "do not use .onmicrosoft.com for production break glass"
Why it matters: Some security architects deliberately use .onmicrosoft.com for break glass because it survives custom domain deprovisioning. Others prefer custom domains for consistency. Neither approach is wrong. Presenting one as a hard rule without justification may cause pushback from experienced engineers.
Exact fix: Change to: "Use the tenant's primary custom domain for break glass accounts for consistency with monitoring and alerting. Note: some organisations prefer .onmicrosoft.com to survive custom domain deprovisioning — document the decision and rationale either way."
L2-SOP: Safe Links URL Rewriting Deprecation
What's wrong: Line 1024: "Do not rewrite URLs, do checks via Safe Links API only: No (rewrite for visibility)"
Why it matters: Microsoft is moving toward API-only checks for modern clients (Outlook desktop, Teams). URL rewriting will remain for OWA and legacy clients but is no longer the recommended primary approach. Setting rewrite to "Yes" today is not wrong, but the document should acknowledge the direction.
Exact fix: Add a note: "Note: Microsoft is transitioning to API-only Safe Links checks for modern Outlook clients. URL rewriting remains necessary for OWA and legacy clients. Review this setting at next quarterly review to align with Microsoft's deprecation timeline."
DOCUMENT 2: IS18 Compliance Mapping
High
H1-IS18: PIR Timeline Inconsistent with CW SLA Definition
What's wrong: Line 50: "PIR conducted within 5 business days of incident closure"
Why it matters: The CW Manage SLA document defines PIR completion at 14 calendar days (SLA "PIR - 14 Day", resolution 336 hours). The IS18 mapping claims 5 business days (~7 calendar days). An auditor comparing these documents will find a contradiction. Engineers won't know which deadline to follow.
Exact fix: Align to one value. Recommended: change IS18 mapping to "PIR conducted within 10 business days (14 calendar days) of incident closure" to match the CW SLA, or tighten the CW SLA to 5 business days if that's the genuine target. Whatever you choose, update BOTH documents.
H2-IS18: Monitoring Tool Reference Misaligned with Official Tool Stack
What's wrong: Line 36: monitoring tools list included a tool not in the official Netier stack.
Why it matters: All monitoring references must match the official tool stack (NinjaOne, CW Manage, ThreatLocker, Sophos MDR, etc.) to avoid nonconformity during IS18 audit.
What's wrong: Line 30: "Automated access reviews for privileged roles (monthly); all-staff access review quarterly; stale account detection (90 days inactive = disabled)"
Why it matters: The SOP covers PIM but not Access Reviews. The IS18 mapping claims Access Reviews as a control for IS18 Family 5 (Access Control), but there is no procedure to configure or operate them. The claim is accurate only at Enterprise tier (requires Entra ID Governance licences), but it's listed without tier qualification in the control row.
Exact fix: Add a tier note: "Entra ID Access Reviews: automated monthly reviews for privileged roles (Enterprise tier); manual quarterly reviews with documented evidence (Professional/Essential tier). See Access Review SOP [to be created]."
M2-IS18: QGISCF Label Mapping Not Specified
What's wrong: Recommendation 3 (line 127) says to "Map M365 Sensitivity Labels to the Queensland Government Information Security Classification Framework" but the mapping itself is not provided.
Why it matters: This is the most actionable recommendation in the document but it stops short of delivering the actual mapping. The document identifies the gap but doesn't close it.
What's wrong: The Explore agent found a non-standard backup tool referenced in the BCP (Business Continuity Plan) alongside Veeam.
Why it matters: Only production-approved tools should appear in client-facing compliance documentation.
Exact fix: BCP updated to reference only the client-facing backup tools (Veeam/AFI.ai).
DOCUMENT 3: Right-to-Refuse Email Templates
High
H1-EMAIL: Compliance Readiness Score Has No Scoring Methodology
What's wrong: Template 2 (line 72): "your environment received a Compliance Readiness Score of [X]/100" and (line 74): "Netier requires a minimum score of [X]/100 before an environment can be transitioned."
Why it matters: An account manager using this template needs to fill in a score, but there is no documented methodology for calculating it. What controls contribute? How are they weighted? What constitutes 60/100 vs 80/100? Without a scoring rubric, two AMs assessing similar environments will produce different scores. A client who disputes the score has no reference to examine. A court or regulator examining the walk-away decision would look for a documented, repeatable methodology.
- Per-domain assessment criteria (e.g., "MFA enforced on all users = 15 points, MFA on admins only = 8 points, no MFA = 0 points")
- Minimum passing score and per-domain minimums
- Reference in Template 2: "Refer to the Compliance Readiness Scorecard (attached) for the detailed assessment."
H2-EMAIL: Template 1 Inconsistently Mixes Pre-Written and Placeholder Content
What's wrong: The Identity section (lines 24-27) contains fully written findings ("Multi-factor authentication is not enforced on privileged administrator accounts"). The Patching section (lines 29-31) uses [X] placeholders ("We identified [X] critical CVEs"). The Endpoint section (lines 33-35) mixes both ("approximately [X]% of endpoints have no active protection agent").
Why it matters: An account manager will either: (a) send the template with the Identity section as-is (making it look like every client has the same findings), or (b) assume everything needs rewriting (negating the value of pre-written content). The template should consistently use one approach.
Exact fix: Convert ALL specific findings to parameterised templates:
IDENTITY AND ACCESS MANAGEMENT
[MFA STATUS: e.g., "Multi-factor authentication is not enforced on privileged
administrator accounts" OR "MFA is enforced for administrators but not standard
users" OR "MFA is enforced universally — no finding."]
[SERVICE ACCOUNTS: e.g., "[X] service accounts with domain admin privileges have
passwords that have not been rotated in over [X] months."]
[CA STATUS: e.g., "Conditional Access policies are either absent or not enforced."]
Mark each placeholder with square brackets AND include example text so the AM has a model.
Medium
M1-EMAIL: Seat Count Thresholds Not Documented in Commercial Model
What's wrong: Template 2 (lines 117-124) includes conditional paragraphs for 50+ seats, 20-49 seats, and <20 seats, referencing "full Co-Investment" and "partial Co-Investment." These thresholds don't appear in the SDD or commercial model documentation.
Why it matters: If the thresholds are inaccurate or change, an AM may send an incorrect commercial commitment in writing. A client quoting "you said I qualify for full co-investment at 50 seats" creates a contractual issue.
Exact fix: Either: (a) document the seat count thresholds in the commercial model / SDD with explicit co-investment percentages, and cross-reference from the template, or (b) replace specific thresholds with: "[TIER: Insert co-investment tier per the current Amortized Transformation pricing model. Check with Service Delivery Manager before quoting.]"
M2-EMAIL: SOCI Act Citation Incomplete
What's wrong: Templates 1 and 3 reference "Security of Critical Infrastructure Act 2018 (SOCI)" without noting the substantial amendments, particularly the Security Legislation Amendment (Critical Infrastructure Protection) Act 2022 which expanded the regime significantly.
Why it matters: A client or their lawyer reading "SOCI Act 2018" may look at the original Act and miss the 2022 amendments that introduced the reporting obligations referenced in the email. The citation should be unambiguous.
Exact fix: Change all references to: "Security of Critical Infrastructure Act 2018 (Cth) (as amended)"
Low
L1-EMAIL: No Template 4 for Phase 2 Transition
What's wrong: The template set covers Discovery Findings (Template 1), Remediation Proposal (Template 2), and Walk-Away (Template 3). There is no template for the positive path: "Phase 1 Complete — Welcome to Managed Service."
Why it matters: An AM completing a successful Phase 1 remediation has no templated communication for transitioning the client into Phase 2. This is the most commercially important email in the sequence — it confirms the relationship and sets managed service expectations.
C1-CW: Workflow Rules That Require API Described as Native CW Rules
What's wrong: WF-009 (line 436-440) "PIR Auto-Create" says to create a child ticket when an incident is resolved. WF-010 (line 449-453) "Phishing Fail Remedial" creates a child ticket. WF-013 (line 488-492) "Backup Recovery Auto-Close" triggers on note content containing "BACKUP_SUCCESS_CONFIRMED".
Why it matters: CW Manage workflow rules CANNOT create new tickets, create child tickets, or perform substring matching on internal note content. These three rules as described are UNIMPLEMENTABLE in native CW Manage. An engineer following this guide will configure WF-001 through WF-008 successfully, then hit a wall at WF-009 and waste hours trying to find a feature that doesn't exist. This is the single most dangerous finding in the entire document set.
Exact fix: For each rule, explicitly state the implementation method:
### 4.9 Post-Incident Review Auto-Creation
Field
Value
Implementation Method
CW Manage REST API (via Rewst, Power Automate, or custom middleware)
NOT a native CW workflow rule
CW workflow rules cannot create tickets.
API Implementation:
Configure a CW Manage callback (Setup > Integrations > Callbacks) that fires
on status change to
Resolved for tickets matching Type = Incident Response.
- POST to CW REST API: /v4_6_release/apis/3.0/service/tickets
- Set parentTicketId to link as child
- Copy custom fields from parent
- POST internal note on parent with child ticket reference
Apply the same pattern to WF-010 and WF-013. For WF-013, the callback should trigger on internal note creation, with the middleware checking note content for the success string.
C2-CW: SLA Definition 3.9 (VulnMgmt Standard) Has No Fixed Resolution Hours
What's wrong: Section 3.9 (line 278): "Resolution Hours: Based on CVSS (see Workflow Rule 4.6)"
Why it matters: CW Manage SLA definitions require a fixed numeric value for Resolution Hours. You cannot set an SLA to "varies by custom field." This SLA is literally unconfigurable as written. The CVSS-based priority assignment (WF-006) can SET the priority, and you can have different SLA targets per priority within the SLA, but the SLA definition itself must exist with fixed values.
Exact fix: Replace SLA 3.9 with per-priority targets within the SLA:
C3-CW: CVSS 9.0+ Maps to P1 (WF-006) but Critical Patching SLA Maps to P2
What's wrong: WF-006 (line 396) maps CVSS 9.0-10.0 to P1. But the SLA-to-Priority Mapping table (line 148) maps "Critical/High CVE Patching (48h)" to P2.
Why it matters: A CVSS 9.8 vulnerability arrives. WF-006 sets it to P1. The SLA mapping table says critical patching should be P2. The SLA definition (3.1) says "Priority Override: P1, P2." So the P1 ticket gets the "Security - Critical 48h" SLA with 0.5h response — but the Priority Matrix says P1 response should be 15 minutes (0.25h), not 30 minutes (0.5h). Three systems disagree on what priority and SLA a critical vulnerability gets.
Exact fix: Decide one truth:
- Option A (recommended): Critical patching = P1 everywhere. Update line 148 from "P2 - High" to "P1 - Critical". Update SLA 3.1 to include P1-specific response target of 0.25h.
- Option B: CVSS 9.0+ = P2 (not P1). Update WF-006 to map CVSS 9.0-10.0 to P2 instead of P1.
Whichever option is chosen, the Priority Matrix, SLA Mapping Table, WF-006, and SLA Definitions must all agree. Currently they don't.
C4-CW: No SLA Pause Configuration for Awaiting Statuses
What's wrong: The document defines "Awaiting Vendor" (line 49) and "Awaiting Client" (line 50) statuses but never specifies that these should pause the SLA clock.
Why it matters: In CW Manage, you configure SLA pause behavior per status: Service Board > Status > "Do Not Count Towards SLA" checkbox. Without this, the SLA clock runs while a ticket sits in "Awaiting Vendor" for 3 weeks. You will breach SLA on tickets where Netier has done everything right but the vendor hasn't responded. Your SLA compliance reports will be meaningless — full of false breaches.
Exact fix: Add to Section 1.2 (Status Workflow table), a new column "Pauses SLA":
| Status Name | Status Type | Pauses SLA | Notes |
|---|---|---|---|
| Awaiting Vendor | In Progress | YES | Clock pauses while waiting on external vendor |
| Awaiting Client | In Progress | YES | Clock pauses while waiting on client action/approval |
| All other statuses | ... | NO | SLA clock runs |
Add implementation note: "Configure under Setup > Service Board > Security Operations > Status > [Status Name] > check 'Do Not Count Towards SLA' for Awaiting Vendor and Awaiting Client."
C5-CW: SAT Platform Misalignment in Integration Diagram
What's wrong: Section 7.6 Integration Architecture diagram (line 747): incorrect SAT platform listed as an integration source.
Why it matters: Netier uses uSecure for security awareness training. An engineer building integrations from this diagram needs the correct platform reference. A client seeing this document might question whether Netier knows their own tool stack.
Exact fix: Updated to "uSecure" on line 747. Integration architecture text updated to reference uSecure's API/webhook capabilities.
Why it matters: CW Manage workflow rules cannot perform datetime arithmetic (e.g., "ticket creation time + 12 hours"). They can set static values, copy fields, send emails, and change statuses — but not calculate dates. This means the SOCI 12h and NDB 72h statutory deadlines cannot be auto-populated by a native workflow rule.
NDB = [ticket creation + 72h AEST]. VERIFY AND SET MANUALLY."
Then require the triaging analyst to manually set the custom field.
H2-CW: Slack Webhooks Not Native to CW Manage
What's wrong: WF-001 (line 325), WF-003-005 (lines 357-383), WF-007-008 (lines 412-427) all specify "Send Slack webhook" as a workflow rule action.
Why it matters: CW Manage workflow rules can send emails and trigger callbacks, but they cannot send Slack webhooks natively. An engineer will look for a Slack action in the workflow rule builder and not find it.
Exact fix: Add a global note at the top of Section 4:
SLACK INTEGRATION NOTE: CW Manage workflow rules do not natively support
Slack messaging. All Slack notifications in the rules below require one of:
(b) A Slack integration platform (e.g., Rewst, Gradient MSP)
(c) Email-to-Slack channel integration (each Slack channel has an email address
that can be targeted as an email action recipient in workflow rules)
Option (c) is the simplest and requires no middleware: in Slack, create an email
address for #security-alerts (Channel Settings > Integrations > Send emails to
this channel). Use this email as the notification recipient in CW workflow rules.
H3-CW: P5 Has No Maximum Resolution Target
What's wrong: Priority Matrix (line 138): P5 Resolution = "Per Schedule" and "N/A" for SLA Update.
Why it matters: P5 tickets (Document Reviews, DRP Test Due) have no resolution SLA. They can sit open indefinitely with zero escalation. After 18 months, you'll have 200 stale P5 tickets clogging the board with no mechanism to surface them. SLA compliance reports will show 100% compliance for P5 by default (nothing to breach), masking a backlog.
Exact fix: Set a maximum resolution for P5:
| P5 - Scheduled | 5 | Green | Next Business Day | N/A | 30 calendar days | Business Hours |
Add note: "P5 resolution target of 30 days provides a backstop. For recurring items with longer cadence (e.g., annual DRP test), the actual due date is set by the recurring ticket schedule. The 30-day SLA serves as a maximum time-in-queue."
Why it matters: Netier is an MSP with ~30 clients and a team structure that may not include a dedicated GRC function. If this team doesn't exist in CW Manage, the workflow rule will fail silently (unrouted ticket) or error on save.
Exact fix: Verify the team name matches CW Manage's actual team structure. If no GRC team exists, route to "Security Operations" with a note: "Assign to compliance-responsible team member. Create a CW Manage team 'GRC' when headcount supports it."
M2-CW: "Priority Override" Is Not a CW Manage Field
What's wrong: SLA definitions (Sections 3.1-3.10) include a "Priority Override" field (e.g., line 196: "Priority Override: P1, P2").
Why it matters: "Priority Override" is not a field in CW Manage SLA configuration. SLAs are matched by board, type, subtype, and company — not by priority. Within an SLA, you define separate response/resolution targets per priority level. This non-standard terminology will confuse a CW admin looking for a "Priority Override" setting.
Exact fix: Remove the "Priority Override" row from all SLA definitions. Instead, within each SLA, add a "Priority Targets" sub-table showing response/plan/resolution hours per priority level, matching CW Manage's actual SLA Priority tab.
Low
L1-CW: "Firmware Critical" at P3/14d Seems Slow
What's wrong: Appendix B (line 830): "Firmware Critical" at P3 with a 14-day SLA.
Why it matters: Labeling something "Critical" but giving it a 14-day window and P3 priority creates cognitive dissonance. An auditor or client reading "Critical firmware patch — 14 days" may question whether Netier takes firmware seriously.
Exact fix: Rename to "Firmware / Driver — High Priority" or align with the CVSS-based naming to avoid confusion with "P1 - Critical."
"cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" # Teams (NOTE: EXO+SPO targets already cover Teams data; this targets Teams-specific features)
Clarify coverage overlap
Line 386-387
Microsoft Authenticator: Enable (as fallback during transition, plan to disable push/OTP once FIDO2/WHfB adoption is complete)
Microsoft Authenticator: Enable (required for Phase A — see Deployment Phases below). Disable push/OTP only after >95% of users have registered FIDO2/WHfB and the CA policy is updated to Phase B.
Original text contradicts the CA policy's auth strength requirement
Line 398-399
Choose Phishing-resistant MFA (built-in strength that includes FIDO2 and Windows Hello) / Enable policy: Report-only
Add deployment phases section (see C1-SOP fix above). Phase A uses "Require multifactor authentication", Phase B upgrades to "Phishing-resistant MFA"
Prevents mass lockout
Line 1024
Do not rewrite URLs, do checks via Safe Links API only: No (rewrite for visibility)
Add note: (Review at next quarterly cycle — Microsoft is deprecating URL rewriting for modern clients)
Fully pre-written Identity findings with no placeholders
Convert to parameterised format: [MFA STATUS: e.g., "Multi-factor authentication is not enforced on privileged administrator accounts"]
Consistency with other sections that use [X] placeholders
Line 45
Security of Critical Infrastructure Act 2018 (SOCI)
Security of Critical Infrastructure Act 2018 (Cth) (as amended)
Captures 2022 amendments that introduced reporting obligations
Line 161
Security of Critical Infrastructure Act 2018 (repeated in Template 3)
Security of Critical Infrastructure Act 2018 (Cth) (as amended)
Same as above
Line 72
Compliance Readiness Score of [X]/100
Compliance Readiness Score of [X]/100 (see attached Compliance Readiness Scorecard for detailed methodology)
References the scorecard that needs to be created
Lines 117-124
Specific seat count thresholds (50+, 20-49, <20)
[CO-INVESTMENT TIER: Refer to the current Amortized Transformation pricing model for co-investment eligibility based on seat count. Confirm tier with Service Delivery Manager before sending.]
Seat thresholds not documented in commercial model
ConnectWise Manage SLA Workflows
Section/Line
Current Text
Corrected Text
Reason
Line 278
Resolution Hours
Based on CVSS (see Workflow Rule 4.6)
Replace with per-priority target table (see C2-CW fix)
CW SLA requires fixed numeric resolution hours
Line 148
Critical/High CVE Patching (48h)
P2 - High
Critical/High CVE Patching (48h)
P1 - Critical (if choosing Option A)
Align with WF-006 CVSS 9.0+ = P1 mapping
Line 396
9.0-10.0 (Critical)
P1 - Critical
48 hours
If choosing Option B: change to 9.0-10.0 (Critical)
P2 - High
48 hours
Must align WF-006 with SLA mapping table
Lines 49-50
Awaiting Vendor / Awaiting Client — no SLA pause indicator
Add column: Pauses SLA: YES
Clock must pause during external wait
Line 196 (and all SLAs)
Priority Override
P1, P2
Remove this row. Replace with a priority-level targets sub-table within each SLA
"Priority Override" is not a CW Manage field
Line 325
If Priority = P1: Send Slack webhook to #security-alerts
If Priority = P1: Send Email to security-alerts-slack@netier.slack.com (Slack email integration) OR add middleware note
Slack webhooks not native to CW workflow rules
Line 436-440
WF-009 as workflow rule with "Create Child Ticket" action
Rewrite as API/middleware implementation with callback trigger (see C1-CW fix)
CW workflow rules cannot create tickets
Line 449-453
WF-010 as workflow rule with "Create Child Ticket" action
Same: rewrite as API/middleware implementation
Same reason
Line 488-492
WF-013 triggers on Internal Note containing "BACKUP_SUCCESS_CONFIRMED"
Rewrite as callback-triggered middleware that parses note content
CW rules can't do substring matching on notes
Line 427
Set Custom Field Statutory Deadline = [calculated datetime]
Document as middleware implementation: callback -> calculate dateEntered + 12h/72h -> PATCH custom field
CW rules can't do datetime arithmetic
Line 747
(SAT platform reference)
uSecure
SAT platform aligned to uSecure
Line 138
P5 - Scheduled
...
Per Schedule
Business Hours
P5 - Scheduled
...
30 calendar days
Business Hours
Prevents stale P5 tickets with no backstop
4. MISSING CONTENT
Document
Missing Section/Content
Why It's Needed
Priority
SOP
Service Account & App Registration Handling — No procedure for excluding or securing headless accounts from MFA CA policy
Every production tenant has service accounts. Without guidance, engineers will create insecure broad exclusions or break LOB apps.
P1
SOP
Phased MFA Deployment Plan — No transition strategy from Authenticator to phishing-resistant MFA
The CA policy as written locks out users who haven't registered FIDO2/WHfB keys yet. A two-phase approach is mandatory.
P1
SOP
Entra ID Access Reviews Configuration — IS18 mapping claims automated access reviews but no SOP exists
IS18 Family 5 (Access Control) evidence gap. Assessors will ask for it.
P2
SOP
Guest/External User CA Handling — CA policies target "All users" but no guidance for B2B guests
Guest access to SharePoint/Teams will either be blocked (breaking collaboration) or exempted without compensating controls.
P2
CW SLA
SLA Pause Configuration — No documentation of which statuses pause the SLA clock
Without this, SLA reports are unreliable. Awaiting Vendor/Client tickets will show false breaches.
P1
CW SLA
Middleware Architecture Specification — WF-008/009/010/013 require API middleware but no middleware spec exists
Engineers can't implement 4 of the 13 workflow rules without knowing what middleware platform to use and how.
P1
CW SLA
Company-to-Organisation Mapping Table — Integration section references org matching but no mapping table exists
NinjaOne org names rarely match CW Manage company names exactly. Without a mapping table, tickets land against wrong companies.
P2
CW SLA
SLA Priority-Level Targets — SLA definitions have single response/resolution values, not per-priority
CW Manage SLAs define targets per priority level. Single-value definitions force all priorities to the same target.
P2
Email
Compliance Readiness Scorecard — Template 2 references a score with no scoring methodology
AMs can't produce the score referenced in the email. The commercial conversation stalls.
LAPS = Local Administrator Password Solution. LSA/LSASS = Local Security Authority Subsystem Service. These are completely different technologies. The TCF conflates them. An engineer reading this will misconfigure one or both.
All 9 remaining SOPs were written on 2026-03-26, completing full coverage of the Technical Configuration Framework. Each SOP follows the established template (Document ID, Table of Contents, Prerequisites, Step-by-Step, PowerShell/CLI, Verification Checks, Rollback, Master Checklist, Document History).
TCF Section
Document ID
SOP File
Status
1.0 Infrastructure & Compute
NET-SOP-INFRA-001
SOPs/SOP_Infrastructure_Compute.md
COMPLETE
2.0 Identity & Cloud Workspaces
NET-SOP-IDM-001
SOPs/SOP_Identity_Cloud_Workspaces.md
COMPLETE (6 fixes applied)
3.0 Endpoint Protection & Control
NET-SOP-EP-001
SOPs/SOP_Endpoint_Protection.md
COMPLETE
4.0 Vulnerability Management
NET-SOP-VULN-001
SOPs/SOP_Vulnerability_Management.md
COMPLETE
5.0 Security Awareness & Training
NET-SOP-SAT-001
SOPs/SOP_Security_Awareness.md
COMPLETE (incl. CyberCred)
6.0 Endpoint Management (MDM)
NET-SOP-MDM-001
SOPs/SOP_Endpoint_Management_MDM.md
COMPLETE
7.0 Networking & Perimeter
NET-SOP-NET-001
SOPs/SOP_Networking_Perimeter.md
COMPLETE
8.0 Backup & Disaster Recovery
NET-SOP-BDR-001
SOPs/SOP_Backup_DR.md
COMPLETE
9.0 Remote Monitoring & Management
NET-SOP-RMM-001
SOPs/SOP_RMM_NinjaOne.md
COMPLETE
10.0 Knowledge Management
NET-SOP-KM-001
SOPs/SOP_Knowledge_Management.md
COMPLETE
7.2 IS18 Evidence Artefacts Needed
For the next annual IS18 return, Netier will need to produce:
QGISCF-to-M365 Sensitivity Label Mapping — A table showing how QGISCF classifications map to M365 sensitivity labels, with DLP policies per classification level.
QGCISO Notification Playbook — An addendum to the IRP with specific QGCISO contact details, notification templates, and escalation timelines for IS18 categories.
Physical Security Assessment Template — A standardised checklist for IS18-aligned physical security assessment of QLD client premises during onboarding.
Access Review Evidence Pack — Screenshots or exports from Entra Access Reviews showing monthly privileged role reviews and quarterly all-staff reviews.
Queensland IPP vs Commonwealth APP Comparison — A one-page table showing where Information Privacy Principles differ from Australian Privacy Principles and how Netier's controls address both.
Cryptographic Standards Reference — Map all encryption implementations to ASD-approved algorithms (ISM controls 0471-0499).
Information Transfer Policy — Extend communications security beyond email to cover secure file transfer, USB control, and removable media handling.
7.3 CW Manage Implementation Scripts
The following PowerShell/API scripts should be built to automate manual configuration from the CW SLA document:
Board & Custom Field Provisioner — Script to create the Security Operations board, all statuses, types/subtypes/items, and custom fields via CW REST API. Eliminates 2-3 hours of manual clicking per environment.
Priority: HIGH — build before first deployment
Inputs: CW Manage API credentials, tenant identifier
Structured communication during active incidents: what happened, impact, containment status, next update time.
P3
SDD Addendum — Right to Refuse Clause
Standard contract language for the Right to Refuse clause, for legal review and inclusion in service agreements.
7.5 Automated Drift Detection
These documents will drift out of date. Build the following to prevent it:
Microsoft Entra Change Monitor — Monthly automated check of CA policy state against the SOP baseline. Use Microsoft Graph API to export all CA policies, compare against the documented baseline, flag deviations. Schedule as a CW recurring ticket or NinjaOne scripted task.
CW Board Configuration Validator — Quarterly script that reads the Security Operations board configuration (statuses, types, subtypes, SLA definitions, custom fields, workflow rules) and compares against the documented spec. Outputs a drift report.
IS18 Control Evidence Freshness Check — For each IS18 control row, track the date of last evidence collection. Flag any control where evidence is older than 6 months. Implement as a Confluence page with automated reminders (per TCF Section 10.1).
Document Version & Review Tracker — A single tracking sheet (or CW recurring ticket set) listing all operational documents, their review dates, owners, and next review due dates. The CW SLA document already includes WF-011 for this — ensure it's actually implemented.
SLA Definition Reconciliation — Quarterly comparison of SLA definitions in CW Manage against the documented spec, flagging any manual changes made outside the change management process.
APPENDIX: Documents Referenced
Document
Path
Lines
Original Status
Post-Remediation Status
SOP: Identity, CA & Cloud Workspaces
SOPs/SOP_Identity_Cloud_Workspaces.md
~1,293
AMBER — 3 Critical, 3 High
GREEN — All 6 resolved
IS18 Compliance Mapping
IS18_Compliance_Mapping.md
176
GREEN — 0 Critical, 2 High
GREEN — LAPS/PIR/monitoring tools fixed
Right-to-Refuse Email Templates
Templates/Right_to_Refuse_Email_Templates.md
~220
GREEN — 0 Critical, 2 High
GREEN — All resolved: findings parameterised, SOCI citations fixed, Template 4 added, seat thresholds parameterised
Compliance Readiness Scorecard
Templates/Compliance_Readiness_Scorecard.md
~180
N/A (did not exist)
NEW — NET-TPL-CRS-001: 6-domain, 100-point scoring methodology
CW Manage SLA Workflows
ConnectWise_SLA_Workflows.md
~900
RED — 5 Critical, 3 High
GREEN — All resolved: WF-008/009/010/013 middleware specs, SLA 3.9 per-priority, Slack note, firmware rename
Netier Technical Configurations
Netier_Technical_Configurations.md
~250
Reference — 1 terminology error
GREEN — LAPS corrected, SOP links added to all 10 sections
Netier Master Baseline Framework
Netier_Master_Baseline_Framework.md
~117
Reference — no issues
GREEN — SOP cross-reference table added
NEW: 9 Additional SOPs
SOPs/SOP_*.md (9 files)
~7,045
N/A (did not exist)
NEW — All TCF sections 1.0-10.0 covered
NEW: 5 Baselines (ISM annotated)
baselines/*.md (5 files)
~350
N/A (not in original scope)
GREEN — ~90 ISM control IDs mapped
ADDENDUM: Remediation Status (2026-03-26)
The following items from this review have been resolved in the compliance suite update session of 2026-03-26:
SOP: Identity, CA & Cloud Workspaces (was AMBER — now GREEN)
Issue
Severity
Resolution
C1 — MFA lockout risk
Critical
Added two-phase deployment (Phase A transitional MFA, Phase B phishing-resistant after >95% FIDO2 adoption)
C2 — Weak GUID-based Break Glass password
Critical
Replaced with cryptographically secure 30-char generation using character-array approach
C3 — Policy count mismatch (6 vs 7)
Critical
Corrected to "7 policies total" in Master Checklist
H1 — Deprecated Graph cmdlet
High
Replaced New-MgDirectoryRoleMember with New-MgRoleManagementDirectoryRoleAssignment
H2 — Missing session controls on User Risk
High
Added SignInFrequency = "everyTime"` to both PowerShell and portal instructions
H3 — No service account exclusion guidance
High
Added Managed Identity / Workload Identity / exclusion group guidance with Service Account Register
Baseline Documents
LAPS terminology corrected (Windows LAPS, not legacy LAPS)
PIR timeline alignment verified
SAT platform references aligned to uSecure
Monitoring tool references aligned to NinjaOne/Sophos MDR
SLA pause for Awaiting statuses documented in CW workflows
Additional Completions (2026-03-26)
9 new SOPs written (10 total, covering all TCF 1.0-10.0 sections)
ISM control IDs (ASD ISM March 2026) annotated across all 5 baselines (~90 control references)
CyberCred Security Champions integrated into organisation-context, technology-evidence-inventory, supplementary-controls, and SOP_Security_Awareness
README overhauled with full directory structure, Document IDs, and updated Document Relationships diagram
Master Baseline Framework updated with SOP cross-reference table
Technical Configuration Framework updated with SOP links on all 10 sections
Document IDs assigned to 8 previously unidentified files
QGISCF: M365 Sensitivity Label mapping table created (UNOFFICIAL through PROTECTED)
SOP — Identity, CA & Cloud Workspaces (Medium/Low items):
Teams App ID: Coverage note added explaining EXO/SPO backend overlap
Break Glass .onmicrosoft.com: Guidance softened to document-the-decision approach
Safe Links URL rewriting: Microsoft deprecation timeline note added
Operational Plans:
BCP: Backup tool references aligned to Veeam/AFI.ai (production tools)
Final Status
All 20 Critical and High items: RESOLVEDAll 7 cross-document inconsistencies: RESOLVEDAll Medium and Low items from all 4 documents: RESOLVEDMissing content items from Section 4: ALL ADDRESSEDEnd of Production-Readiness Review