SCM All staff config

Here is the complete configuration walkthrough. I will use FC-04 Malware Protection as the worked example throughout because it has clean, distinct content at all three layers.

---

Architecture overview before you touch anything

The layering model needs to be understood before you write a single macro. SCM variants work on an additive visibility principle, which means the security team should not have to be in three groups to see three layers of content. The correct configuration is:

• Default content (no variant wrapper) — visible to everyone who can view the page
• isms-it-staff variant content — visible to isms-it-staff AND isms-security audiences
• isms-security variant content — visible only to isms-security audience

This means you configure the isms-security audience in SCM to inherit isms-it-staff content, rather than duplicating it. The content hierarchy on a completed Fundamental Controls page looks like this:

┌─────────────────────────────────────────────────────┐
│  ALL STAFF (no variant wrapper)                     │
│  Behavioural guidance, plain-language rules         │
│  What to do if something goes wrong                 │
├─────────────────────────────────────────────────────┤
│  IT STAFF (isms-it-staff variant)                   │
│  Technical procedure, configuration spec            │
│  Tool references, GPO/MDM/Ansible settings          │
├─────────────────────────────────────────────────────┤
│  SECURITY TEAM (isms-security variant)              │
│  Evidence currency checklist                        │
│  MITRE ATT&CK mapping, SIEM rule context            │
│  Assessment preparation notes                       │
└─────────────────────────────────────────────────────┘

---

Step 1 — Confluence group setup

Before SCM can enforce variants, the Confluence groups must exist and be populated. Do this in Confluence Administration first.

Navigate to: Confluence Administration → User Management → Groups → Create Group

Create four groups:

Group name	Members	Purpose
isms-all-staff	All employees, all contractors with system access	Grants view access to the ISMS space and all public sections
isms-it-staff	IT Operations engineers, system administrators	Grants view of technical procedures (Sections 02 and 03)
isms-management	CISO, IT Manager, HR Manager, senior leadership	Grants view of governance sections (risk register, management review)
isms-security	CISO, Security Analyst, IT Manager	Grants view of all content including evidence checklists and assessment guides

Important note on group membership: isms-security members do not need to also be in isms-it-staff. SCM will handle the inheritance — being in isms-security is sufficient to see isms-it-staff content if you configure the variant hierarchy correctly in Step 3.

Apply space permissions: Confluence Administration → Space → Permissions. Grant isms-all-staff view permission on the ISMS space. The more granular page-level restrictions for the Advanced Controls section are applied separately at the page level, not at the space level.

---

Step 2 — Install and configure Scroll Content Manager

If SCM is not already installed, it is available from the Atlassian Marketplace as a K15t product. Post-installation, the configuration panel appears under Confluence Administration → Scroll Content Manager.

Navigate to: Confluence Administration → Scroll Content Manager → Variants

Click Create Variant and create the following three variants. The variant name is what you will reference in the macro on every page.

Variant 1:

Variant name:  isms-it-staff
Display name:  IT Staff — Technical Content
Confluence group:  isms-it-staff

Variant 2:

Variant name:  isms-security
Display name:  Security Team — Full Content
Confluence group:  isms-security
Inherits variants from:  isms-it-staff

The Inherits variants from setting on the isms-security variant is the critical configuration that enables the additive model. With this set, anyone in the isms-security group automatically sees content tagged for isms-it-staff without being in that group and without you duplicating the content.

Variant 3 (optional but recommended for management content on other pages):

Variant name:  isms-management
Display name:  Management — Governance Content
Confluence group:  isms-management

---

Step 3 — The macro syntax

SCM uses the scroll-content macro family. The specific macro you need for variant-based visibility is {scroll-content:variant=VARIANTNAME}. In the Confluence page editor, you insert this through the macro browser, or in the wiki markup editor you type it directly.

Macro browser path: Insert → Other Macros → Scroll Content Manager → Content Variant

Wiki markup syntax:

{scroll-content:variant=isms-it-staff}
Your IT-staff-only content goes here.
{scroll-content}

{scroll-content:variant=isms-security}
Your security-team-only content goes here.
{scroll-content}

Visual editor behaviour: in the Confluence visual editor, the macro appears as a coloured block with a label showing the variant name. All-staff content sits outside any macro block. IT-staff content sits inside a block labelled isms-it-staff. Security content sits inside a block labelled isms-security. The page author sees all three layers simultaneously in the editor, with the variant blocks visually distinguished by colour.

---

Step 4 — The complete worked example

Here is the full page content for FC-04 Malware Protection with all three layers marked up. I will show it in wiki markup first, then explain what each user group sees.

h1. FC-04 · Malware Protection

This page explains how the organisation protects against malicious software 
and what you need to do to keep that protection effective.

----

h2. What malware is and how it arrives

Malware — malicious software — is any program designed to damage, disrupt, 
or gain unauthorised access to your device or data. It arrives via email 
attachments, malicious links, USB drives, and downloads from unofficial 
sources. Ransomware is the most destructive current variant — it encrypts 
your files and demands payment.

h2. What the organisation does to protect you

We deploy endpoint protection software on every company device. This runs 
continuously, receives daily signature updates, and monitors for suspicious 
behaviour. The email gateway scans attachments before they reach your inbox. 
The web proxy blocks known malicious sites. You benefit from all of this 
automatically.

h2. What you must do

* Do not open attachments from unexpected senders.
* Do not click links in emails without verifying the destination URL 
  (hover over the link first — do not click).
* Report suspicious emails using the phishing report button in Outlook. 
  Do not forward them to colleagues.
* Do not plug USB drives into your device without IT Operations approval.
* If your device generates a security alert, do not dismiss it — 
  contact IT Operations.
* If you suspect your device has been infected: do not power it off, 
  do not run removal tools yourself, call IT Operations immediately.

h2. What to do if something goes wrong

Report immediately to IT Operations: [phone number] / [helpdesk URL]

Security team 24-hour contact: [phone number]

If you see a ransomware notice on your screen: disconnect from the network 
(unplug the cable or disable Wi-Fi), then call IT Operations. Do not pay. 
Do not try to remove it yourself.

----

{scroll-content:variant=isms-it-staff}

h2. Technical implementation — IT staff

h3. AV/EDR deployment specification

The endpoint protection platform is [Product name — e.g. Microsoft Defender 
for Endpoint / CrowdStrike Falcon / SentinelOne]. Deployment covers:

* Windows endpoints: deployed via Intune MDM policy, mandatory, 
  cannot be disabled by user. Signature updates: every 4 hours. 
  Cloud-delivered protection: enabled. Real-time protection: enabled.
* macOS endpoints: deployed via Jamf configuration profile. 
  Real-time protection: enabled.
* Linux servers (CUI scope): deployed via Ansible playbook. 
  Configured in audit + prevent mode.

GPO path for Windows AV settings:
Computer Configuration → Administrative Templates → 
Windows Components → Microsoft Defender Antivirus

Required settings:
  Turn off Microsoft Defender Antivirus = Disabled
  Turn off real-time protection = Disabled
  Configure detection for potentially unwanted applications = Enabled: Block

h3. Coverage verification

Monthly AV coverage report (EV-D32) is generated from the EDR management 
console. Acceptable coverage threshold: 100% of CUI-scope endpoints. 
Any device showing as unprotected or with signatures >48 hours old is 
flagged to IT Operations for immediate remediation.

SIEM integration: AV events forwarded to SIEM within 60 seconds. 
Alert rules active for:
  - Threat detected (any severity)
  - Protection disabled on any device
  - Signature age exceeding 48 hours on any CUI-scope device

h3. Removable media technical controls

USB mass storage blocked via:
  Windows: GPO → All Removable Storage Classes: Deny all access
  macOS: MDM restriction profile → Removable storage = Blocked
  Linux: usb-storage blacklisted in /etc/modprobe.d/blacklist.conf

EDR device control policy configured to alert on any USB storage 
connection regardless of OS-level block status. Alert feeds to SIEM.

Exception process: CISO approval + EDR whitelist by device serial number. 
Exception register maintained in EV-D19.

h3. Diagnostic media scan procedure

All vendor-supplied diagnostic media scanned on isolated scanning 
workstation (not CUI-network connected) before use. 
Full procedure in AT-MA Section 5. Evidence filed in EV-D32M.

{scroll-content}

----

{scroll-content:variant=isms-security}

h2. Evidence checklist — security team

Use this checklist monthly when completing the log review and quarterly 
before any assessment. Status column updates are the Security Analyst's 
responsibility.

|| Evidence ID || Item || Required frequency || Last produced || Status ||
| EV-D32 | AV/EDR coverage report — 100% CUI-scope coverage confirmed | Monthly | [date] | [Current / Overdue] |
| EV-D06 | Vulnerability scan reports — authenticated, all CUI-scope systems | Monthly | [date] | [Current / Overdue] |
| EV-D07 | Patch tracking register — all Critical within 7 days, High within 14 | Weekly review | [date] | [Current / Overdue] |
| EV-D08 | Patch exception register — all exceptions with CISO approval | Per exception | [date] | [Current / N/A] |
| EV-D19 | Removable media policy baseline — USB block settings confirmed | Annual + on change | [date] | [Current / Overdue] |
| EV-D20 | Quarterly config audit — AV settings verified, USB block verified | Quarterly | [date] | [Current / Overdue] |
| EV-F01 | Monthly SIEM log review — AV alerts reviewed, USB events reviewed | Monthly | [date] | [Current / Overdue] |
| EV-F04 | IDS/IPS alert review — malware-related alerts correlated | Monthly | [date] | [Current / Overdue] |

h3. MITRE ATT&CK context for log review

When reviewing EV-F01 and EV-F04, actively look for indicators of these 
techniques that malware protection controls are designed to detect:

* T1566 (Phishing) — email gateway block events for malicious attachments; 
  unexpected macro execution events in Office applications
* T1055 (Process Injection) — EDR flagging process spawning anomalies; 
  parent-child process relationships that are unusual 
  (e.g. Word spawning cmd.exe or PowerShell)
* T1059 (Command and Scripting Interpreter) — PowerShell Script Block 
  Logging events (Windows Event ID 4104) showing unexpected script execution
* T1486 (Data Encrypted for Impact — ransomware) — rapid file extension 
  changes across multiple directories; high volume file write events 
  from a single process; shadow copy deletion commands
* T1070.001 (Indicator Removal: Clear Windows Event Log) — 
  Windows Event ID 1102 on any CUI-scope system is a Critical alert

h3. Control effectiveness assessment — quarterly

Complete this section each quarter as part of the internal assessment programme 
(AT-CA 3.12.1).

|| Control || Last technical test || Result || Trend || Notes ||
| AV real-time protection active on all CUI-scope devices | [date] | Pass/Fail | ↑↓→ | |
| AV signatures current (<48h) on all CUI-scope devices | [date] | Pass/Fail | ↑↓→ | |
| USB block active — Windows GPO verified on 3 sample devices | [date] | Pass/Fail | ↑↓→ | |
| USB block active — macOS MDM profile verified on 3 sample devices | [date] | Pass/Fail | ↑↓→ | |
| USB block active — Linux modprobe blacklist verified on 3 sample servers | [date] | Pass/Fail | ↑↓→ | |
| EDR alerts reaching SIEM within 60 seconds (test alert verified) | [date] | Pass/Fail | ↑↓→ | |
| Patch compliance rate — Critical vulnerabilities within 7-day SLA | [date] | [%] | ↑↓→ | |

h3. Assessment preparation — C3PAO examiner focus

The assessor will examine: AV coverage report (EV-D32) confirming 100% 
of CUI-scope devices; scan reports (EV-D06) confirming authenticated monthly 
scans; patch register (EV-D07) confirming SLA measured from vendor release date.

The assessor will test: attempt to disable AV on a test device from a standard 
user account (confirm blocked by GPO); connect a test USB to a CUI-scope 
endpoint (confirm blocked and SIEM alert fires within 60 seconds); request 
demonstration of an authenticated scan in the scanner management console.

Common finding to prevent: AV coverage showing 99% instead of 100% because 
one device enrolled in MDM but not yet receiving AV policy. Check MDM 
compliance report before any assessment for unprotected devices.

{scroll-content}

---

Step 5 — What each user group actually sees

isms-all-staff user visiting the page:

They see everything outside the variant macro blocks. In this example that is the introductory paragraph, "What malware is and how it arrives," "What the organisation does to protect you," "What you must do," and "What to do if something goes wrong." The IT-staff and security-team sections are completely invisible — not collapsed, not greyed out, not hinted at. They simply do not exist in the rendered page.

isms-it-staff user visiting the page:

They see all of the all-staff content as above, plus the "Technical implementation — IT staff" section with the AV deployment specification, GPO settings, coverage verification procedure, removable media technical controls, and diagnostic media scanning reference. The security-team evidence checklist remains invisible.

isms-security user visiting the page:

They see everything. All-staff content, IT-staff technical content (via inheritance configured in Step 3), and the security-team evidence checklist with the currency table, MITRE ATT&CK context, control effectiveness assessment, and assessment preparation notes.

---

Step 6 — Testing the configuration

Test all three views before publishing the page to a live audience. There are two ways to do this.

Method 1 — SCM preview mode: in the Confluence page editor, SCM adds a variant selector to the page preview toolbar. Use the dropdown to switch between "All content," "isms-it-staff view," and "isms-security view" and verify the page renders correctly for each audience. This is the fastest way to verify during authoring without needing to log in as different users.

Method 2 — Real user testing: create three test accounts, assign each to one of the three groups, and view the page as each test user. This confirms the live rendering matches the preview and that the Confluence group → SCM variant mapping is working correctly. Test all three in sequence on the same page.

What to check in each view:

For all-staff: confirm no variant block content bleeds through. Confirm the page renders cleanly with no visible section separators where the IT-staff or security content would appear. Confirm links and callout boxes in the all-staff section work correctly.

For IT-staff: confirm the all-staff content appears first, followed by the technical implementation section. Confirm the security checklist does not appear. Confirm any tables or code blocks in the technical section render correctly.

For security: confirm all three sections appear in the correct order — all-staff, then IT-staff technical, then security checklist. Confirm the evidence table renders with editable status cells if you are using a table that should be updated by the security team. Confirm the quarterly control effectiveness table is visible and editable.

---

Step 7 — Page-level access controls versus SCM variants

These are separate mechanisms and both must be correctly configured on the Advanced Controls pages (Section 03). They serve different purposes.

SCM variants control what content within a page is visible to different audience groups. A user who can view the page sees only the content tagged for their variant.

Confluence page-level restrictions control whether a user can view the page at all. For the AT-[family] pages in Section 03, the page should have a restriction preventing isms-all-staff from viewing it — regardless of SCM variants, those users should not be able to reach the page.

The correct configuration for a Section 03 Advanced Controls page is therefore:

Page restriction: View — isms-it-staff, isms-security, isms-management
(isms-all-staff is explicitly excluded — they get a 403 if they navigate 
to the URL directly or find it in search)

SCM variants on the page:
  Default content (no variant) — visible to all who can view the page
  isms-security variant — visible only to isms-security

For Section 02 Fundamental Controls pages — the ones you are configuring in this guide — the page restriction is different:

Page restriction: View — all users (inherited from space permission for 
isms-all-staff, or no restriction at page level)

SCM variants on the page:
  Default content — visible to all-staff, IT-staff, and security
  isms-it-staff variant — visible to IT-staff and security (via inheritance)
  isms-security variant — visible to security only

---

Step 8 — Content maintenance discipline

The variant structure creates a discipline obligation: when the page is updated, the author must update the correct layer. Three common authoring mistakes to avoid.

Mistake 1 — Putting IT content in the all-staff layer. If a procedure or technical specification appears outside a variant macro block, every employee sees it. Audit new edits to confirm technical content is always within the appropriate variant macro.

Mistake 2 — Putting evidence checklists inside the isms-it-staff block instead of isms-security. Evidence checklists belong in the isms-security layer. IT staff configure controls; security staff verify and evidence them. The distinction is operationally meaningful and should be reflected in the variant assignment.

Mistake 3 — Updating only one layer when a control changes. When a control is reconfigured — the AV product changes, a new GPO setting is applied, an evidence item is renumbered — all three layers that reference it may need updating. The all-staff "what to do if something goes wrong" section, the IT-staff technical specification, and the security-team evidence checklist may all reference the changed element. Build a review of all three layers into any change management process that affects a control documented in the Fundamental Controls section.

---

Variant quick reference summary

Content type	Layer	Macro	Who sees it
Behavioural guidance, plain rules, what to do	All staff	None — outside any macro	isms-all-staff, isms-it-staff, isms-security
Technical specification, GPO settings, tool config	IT staff	{scroll-content:variant=isms-it-staff}	isms-it-staff, isms-security
Evidence checklist, ATT&CK mapping, assessment prep	Security	{scroll-content:variant=isms-security}	isms-security only
Governance metrics, risk decisions	Management	{scroll-content:variant=isms-management}	isms-management only