Foreword
I've spent twenty years running IT for small and mid-sized organisations, and the same pattern shows up everywhere. The problems that hurt a business are rarely exotic. They're a backup nobody tested, an admin account nobody owns, a server out of support, a licence nobody reviewed. Frameworks describe the destination well, but turning them into specific checks for real systems is where most efforts stall, so the checks never happen.
I put a process in place to close those gaps in the environments I was responsible for, then built Spectra Core so that IT teams and providers could run the same process themselves. This baseline sets out the controls behind that process, openly, so organisations, their IT providers and the bodies that represent them can use it and help improve it.
Christian W. Chu Fook
Founder, Spectra Core
linkedin.com/in/cchufook
Why this baseline exists
Technology risk sits with every organisation, not only those large enough to employ security and compliance specialists. Credit unions, insurance brokers, law firms and other small and mid-sized organisations hold data and run systems their members and clients depend on, usually with a small IT team or an outside provider. Their leaders are accountable for that risk.
Why controls alone aren't enough
Frameworks and control catalogues say what must be true: access is controlled, systems are patched, backups can be restored. Before any of that can be checked, someone has to translate each control into specific checks on the organisation's own systems: which settings on the email platform, which accounts on the firewall, what evidence proves it. That translation has to be done for every system and redone as systems change. It needs people who understand both the framework and the technology, and it takes time few small organisations have. So it is often skipped. Assessments fall back on policies and attestations, or on a spreadsheet that goes out of date, and the gaps that cause real incidents stay unchecked.
This baseline starts from the other end. Its standards were written for the systems small organisations actually run, refined in live environments, and then grouped into controls. Each control is checked system by system, so a system left out of an assessment shows up as a gap instead of being silently skipped. Alongside security, the baseline covers the operational practices that keep IT running well, such as licensing, documentation and capacity. Recognised frameworks, including NIST CSF 2.0 and the CIS Controls, and common cyber insurance questions are used to confirm nothing important is missing, not as the starting point.
It is written for the leaders accountable for technology risk, the IT teams and providers who manage it, and the industry bodies that set expectations for their members.
How to use this baseline
From controls to standards
A control states what must be true. It doesn't say what to check on a particular system: that is what a standard does. Standards are written for each system type a control applies to, so the same control is checked separately on the email platform, the VPN and the firewall.
ControlWhat must be true, stated once.
StandardThe specific check on each system type the control applies to.
EvidenceWhat the check looks at, and keeps as proof.
GapA standard that isn't met. It gets fixed, or the decision not to fix it is recorded.
Two rules keep the library consistent. Every standard rolls up to a control. And every control that applies to a system type in the environment should have a standard for that system type; where one doesn't, the gap is visible rather than hidden. Controls won't match an audit report line for line, and no framework does: one control becomes several standards, and some standards cover operational practices no security framework asks about.
Reading a control
Each control shows its scope, Organisation-wide when it is met once for the whole organisation or System-specific when it is met for each system type it applies to; the system types; the number of standards behind it today; the evidence that shows it is met; and one or two of the standards that check it. The examples are a sample, not the full set: the complete library of standards is part of Spectra Core, and organisations using the baseline without it can write their own standards for each control, using the examples as a guide. Control IDs begin with SCB, the prefix of Spectra Core's baseline library, and never change. Standard IDs add the system type and a sequence to the control ID: SCB-ACC-03.EML.1 is the multi-factor authentication check on the email and collaboration platform.
System types
EMLEmail and collaboration platform
DIRDirectory and domain
NETNetwork devices: firewalls, switches, wireless
RMTRemote access: VPN and overlay networks
BKPBackup system
RMMIT provider's remote management tool
SRVServers and virtualisation hosts
ENDWorkstations and laptops
WEBCustomer-facing online services
LOBLine-of-business applications
DMSFile shares and document management
CAMVideo surveillance
TELTelephony
How Spectra Core supports the process
The baseline can be run with a spreadsheet and discipline. Spectra Core was built to make the process repeatable for internal IT teams and MSPs, with each role doing the part it is best placed to do.
EngineerKnows the systems. Is assigned standards by area of expertise, carries out the checks, and submits findings with supporting evidence such as screenshots.
Audit ownerUsually the IT manager or director. Sets up the audit, reviews the findings, marks each standard aligned or not aligned, sets risk levels and writes the recommendations.
LeadershipReceives the report, decides what to fix and when, and owns any decision not to.
1. Set upAudit ownerCreate an audit, or reuse a previous one's structure. Select the standards libraries for the parts of the environment being audited, including custom ones, and exclude anything that doesn't apply.
2. AssignAudit ownerAssign standards to engineers by expertise, or every standard to one IT generalist on a small team. Daily email reminders keep outstanding standards moving.
3. CheckEngineerEngineers carry out each check and submit findings with supporting evidence, working with the audit owner inside each standard.
4. ReviewAudit ownerThe audit owner reviews the findings, marks each standard aligned or not aligned, sets its risk level, and writes a recommendation for anything not aligned, with quotes or proposals attached where useful.
5. ReportLeadershipAn AI-generated executive summary heads a report shared securely with leadership, who can filter it by alignment status, impact and risk level, and print it.
Every standard carries a risk level, a review frequency and a plain-language rationale. Audits can be as focused as one area checked monthly or as broad as a full annual pass, so leadership sees a current picture rather than an annual snapshot. On larger teams the audit owner reviews the engineers' work; on small ones a single person can run the whole audit. The baseline can be used with or without Spectra Core.
More detail on what Spectra Core tracks and how it works: spectracore.io/how-it-works
Adoption and co-authorship
This baseline is meant to be shared. It is licensed under CC BY 4.0, so no permission is needed to adopt or adapt it, only credit to Spectra Core. Industry associations, federations, leagues and other representative bodies are invited to adopt it for their members, adapt it into editions for their sector or region, or co-author future versions. Sector and regional editions keep the same control IDs, so organisations, their IT providers and their representative bodies can work from a common reference. Spectra Core publishes and maintains the baseline; to discuss adoption or co-authorship, contact Spectra Core through spectracore.io.
What this version covers
This is the first published version. Every control in it is backed by standards in use in live environments today. Future versions will add controls as the library grows.
Part 1 · Security controls
ACC · 5 controls
Identity and access
Who can get in, how they prove who they are, and who has admin rights.
SCB-ACC-01Access is removed promptly when it is no longer needed: leavers' accounts are disabled, and stale accounts, remote access users and overlay network members are reviewed on a set cycle. System-specific System types DIR, EML, RMT Standards 4
Evidence Leavers matched to disable dates; dated reviews of stale accounts and remote access users.
Example standards
SCB-ACC-01.EML.1Are past employees' email accounts disabled?SCB-ACC-01.DIR.1Are stale directory accounts disabled?SCB-ACC-01.RMT.1Does everyone with VPN access still work for the organisation?
SCB-ACC-02The organisation approves who has access: group memberships, management console access and application permissions are reviewed and signed off. System-specific System types DIR, EML, NET Standards 4
Evidence The organisation's signed approval of group memberships, console access and application permissions.
Example standards
SCB-ACC-02.DIR.1Has the organisation approved the users in each directory group?SCB-ACC-02.NET.1Can only authorised users reach the management consoles of network devices?
SCB-ACC-03Multi-factor authentication is enforced for every user on email and cloud services, and on all remote access. System-specific System types EML, RMT Standards 2
Evidence MFA status for every user on each email, cloud and remote access service.
Example standards
SCB-ACC-03.EML.1Is multi-factor authentication enabled for every user on the email and collaboration platform?SCB-ACC-03.RMT.1Does the VPN enforce multi-factor authentication?
SCB-ACC-04Administrative rights are limited to named administrators: users work without local admin rights, default administrator accounts are disabled, and every admin account belongs to one person. System-specific System types DIR, EML, END, NET Standards 5
Evidence Accounts with admin rights, each named to one person; default admin accounts disabled.
Example standards
SCB-ACC-04.END.1Do users work without local administrator rights on their computers?SCB-ACC-04.DIR.2Is the built-in domain Administrator account disabled?
SCB-ACC-05Administrative and device credentials are strong, rotated on a set cycle and recorded securely: domain, local administrator, out-of-band management, network device and cloud administrator accounts. System-specific System types DIR, EML, NET, SRV Standards 7
Evidence Credential register showing rotation dates and secure storage for each admin and device account.
Example standards
SCB-ACC-05.SRV.2Are local administrator passwords on servers and workstations complex, unique, rotated and recorded?SCB-ACC-05.NET.1Is the admin password on each network device rotated and recorded?
PLT · 4 controls
Platform security
Supported, patched, consistently configured and protected systems.
SCB-PLT-01Systems run supported versions: operating systems, directory functional level, workstation hardware, telephony and line-of-business applications all have active vendor support. System-specific System types DIR, END, LOB, SRV, TEL Standards 5
Evidence Versions and vendor support status for each system.
Example standards
SCB-PLT-01.SRV.1Do all servers run a currently supported operating system?SCB-PLT-01.LOB.1Does every line-of-business application have a vendor support agreement?
SCB-PLT-02Security updates are applied on a set cycle and measured: every device is in the patching policy, patch levels meet a set minimum, and firmware, agents and clients are current. System-specific System types CAM, LOB, NET, RMM, RMT, SRV Standards 8
Evidence Patch compliance against the set minimum; firmware, agent and client versions.
Example standards
SCB-PLT-02.SRV.2Is every Windows machine included in the patching policy?SCB-PLT-02.NET.1Is network device firmware on the latest stable release?
SCB-PLT-03A standard security configuration is enforced and checked for drift. System-specific System types DIR, END Standards 2
Evidence The configuration baseline and the latest drift check.
Example standards
SCB-PLT-03.END.1Are device management policies enforced on every computer?SCB-PLT-03.DIR.1Is reversible password encryption disabled in the directory?
SCB-PLT-04Endpoint protection (endpoint detection and response, or managed anti-malware) runs on every workstation and laptop with current definitions. Organisation-wide System types END Standards 2
Evidence Console report showing coverage and definition dates for every workstation and laptop.
Example standards
SCB-PLT-04.END.1Is endpoint protection deployed to every workstation and laptop?SCB-PLT-04.END.2Are endpoint protection definitions up to date?
NET · 3 controls
Network security
Segmentation, wireless and remote connections.
SCB-NET-01The network is segmented: corporate, guest, voice, remote access, surveillance and audio-visual traffic run on separate network segments. Organisation-wide System types NET Standards 6
Evidence Network segment map showing each traffic type separated.
Example standards
SCB-NET-01.NET.2Is public Wi-Fi on its own network segment?SCB-NET-01.NET.4Is video surveillance on its own network segment?
SCB-NET-02Wireless networks use current encryption, and guest wireless is isolated from the corporate network. Organisation-wide System types NET Standards 2
Evidence Wireless configuration showing encryption and guest isolation.
Example standards
SCB-NET-02.NET.1Are public wireless networks on a separate subnet, firewalled from the corporate network?SCB-NET-02.NET.2Do private wireless networks use WPA3 encryption?
SCB-NET-03Remote access and site-to-site links use modern protocols and strong, rotated keys, and overlay networks are private. System-specific System types RMT Standards 4
Evidence Remote access and site-to-site configuration: protocol, key rotation dates, overlay network settings.
Example standards
SCB-NET-03.RMT.1Does the VPN use a modern protocol?SCB-NET-03.RMT.3Are site-to-site VPN keys rotated?
DAT · 2 controls
Data protection
Who can reach shared data, and the certificates that protect services.
SCB-DAT-01Shared data follows least privilege: file share and collaboration permissions are documented, audited and approved by the organisation. System-specific System types DMS, EML Standards 4
Evidence Permission documentation, the latest audit and the organisation's approval.
Example standards
SCB-DAT-01.DMS.3Has the organisation approved file share permissions?SCB-DAT-01.EML.1Has leadership approved the permissions on collaboration spaces?
SCB-DAT-02Certificates that protect services are recorded with their expiry dates and renewed before they lapse. System-specific System types WEB Standards 1
Evidence Certificate register with expiry dates and renewal records.
Example standards
SCB-DAT-02.WEB.1Are certificates recorded with their expiry dates?
BKR · 5 controls
Backup and recovery
Backups that exist, work, sit off site, and recover within agreed times.
SCB-BKR-01Every system holding important data is backed up: servers, endpoints with critical data, cloud email and files, line-of-business data and device configurations. System-specific System types CAM, EML, END, LOB, NET, SRV Standards 11
Evidence Backup coverage showing each system and its last successful backup.
Example standards
SCB-BKR-01.SRV.3Are mission-critical servers protected by the backup system?SCB-BKR-01.EML.1Is every user included in the email and file backup?
SCB-BKR-02Backups are monitored and verified: recent jobs succeed, verification runs, and alerts are cleared. System-specific System types EML, END, SRV Standards 6
Evidence Backup job history, verification results and alert status.
Example standards
SCB-BKR-02.SRV.3Did the latest backup verification succeed?SCB-BKR-02.EML.1Have email and file backups succeeded on each of the last three days?
SCB-BKR-03Backups are kept off site for the agreed retention: copies replicate to a geographically separate location and retention meets the organisation's requirements. Organisation-wide System types BKP, EML, SRV Standards 3
Evidence Replication status to the off-site location; retention settings.
Example standards
SCB-BKR-03.BKP.1Are backups held in a geographically separate location?
SCB-BKR-04Recovery objectives are agreed with the business and proven: recovery time and point objectives are defined, the recovery environment matches production, and a full failover shows systems recover within the objective. Organisation-wide System types BKP Standards 3
Evidence Agreed recovery objectives; the latest failover test showing recovery within them.
Example standards
SCB-BKR-04.ALL.1Are recovery time and recovery point objectives defined and agreed with the business?SCB-BKR-04.BKP.1Has a full failover test recovered systems within the recovery time objective?
SCB-BKR-05Critical processes can continue manually when a line-of-business system is offline. Organisation-wide System types LOB Standards 1
Evidence Documented manual procedures for each critical process.
Example standards
SCB-BKR-05.LOB.1Is there a manual process to keep working if a line-of-business system is offline?
AVL · 2 controls
Availability
Redundancy and spares so a single failure doesn't stop the business.
SCB-AVL-01Critical infrastructure has no single point of failure: redundant directory servers, redundant storage, healthy clusters and dual internet connections. System-specific System types DIR, NET, SRV Standards 5
Evidence Redundancy status for directory servers, storage, clusters and internet connections.
Example standards
SCB-AVL-01.DIR.1Is a second domain controller in place and replicating?SCB-AVL-01.NET.1Does the internet connection fail over to a second provider?
SCB-AVL-02Spare network hardware for each device type is kept on site. System-specific System types NET Standards 4
Evidence Spares list for each network device type, with location.
Example standards
SCB-AVL-02.NET.1Is a spare router kept on site?SCB-AVL-02.NET.2Is a spare switch kept on site?
PHY · 4 controls
Physical and environmental
The rooms, racks, cameras, access control and power that physical security depends on.
SCB-PHY-01Server rooms and racks are secured: equipment sits in dedicated rooms, racks are locked with keys controlled, and physical access rights are reviewed. Organisation-wide System types Organisation-wide Standards 4
Evidence Room and rack inspection; key holder list; dated review of physical access rights.
Example standards
SCB-PHY-01.ORG.3Are server racks locked, with keys secured?SCB-PHY-01.ORG.4Are physical access rights reviewed?
SCB-PHY-02Physical security systems work and are watched: cameras and recorders are online with adequate coverage, access-control systems are operational, and their logs are reviewed. Organisation-wide System types CAM Standards 5
Evidence Camera, recorder and access-control status; coverage check; log review record.
Example standards
SCB-PHY-02.CAM.2Are all cameras online?SCB-PHY-02.ORG.1Are access-control logs reviewed?
SCB-PHY-03Critical equipment is protected from power loss: servers have enough UPS runtime and shut down cleanly, and a working generator is available. Organisation-wide System types Organisation-wide Standards 5
Evidence UPS runtime and shutdown test; generator test record.
Example standards
SCB-PHY-03.ORG.1Do UPS units give at least 15 minutes of runtime?SCB-PHY-03.ORG.5Is the generator working?
SCB-PHY-04Server and rack rooms are kept cool enough for the equipment. Organisation-wide System types Organisation-wide Standards 2
Evidence Temperature readings for each server and rack room.
Example standards
SCB-PHY-04.ORG.1Is the server room kept at 24°C or below?
AST · 1 control
Asset management
Knowing which devices exist and which hold critical data.
SCB-AST-01Devices are fully inventoried and managed: every computer appears in both remote management and device management, and endpoints holding critical data are recorded. Organisation-wide System types END Standards 2
Evidence Device lists from remote management and device management, reconciled; endpoints holding critical data recorded.
Example standards
SCB-AST-01.END.1Does every computer appear in both remote management and device management?
INC · 2 controls
Incident and problem management
A plan for incidents, and learning from recurring problems.
SCB-INC-01An approved, signed incident response plan exists. Organisation-wide System types Organisation-wide Standards 1
Evidence Signed incident response plan with its approval date.
Example standards
SCB-INC-01.ORG.1Is there an approved, signed incident response plan?
SCB-INC-02Tickets are reviewed for recurring issues, and their root causes are addressed. Organisation-wide System types Organisation-wide Standards 1
Evidence Dated ticket review with recurring issues and the actions taken.
Example standards
SCB-INC-02.ORG.1Are tickets reviewed for recurring issues and their root causes?
PEO · 1 control
People
What users are told about working safely.
SCB-PEO-01Users are reminded of safe working practices, such as where to save files and why it matters. Organisation-wide System types Organisation-wide Standards 1
Evidence Record of reminders sent to users.
Example standards
SCB-PEO-01.ORG.1Are users reminded where to save files?
MON · 1 control
Security monitoring
Security monitoring by a dedicated service.
SCB-MON-01Security events on cloud services are monitored by a dedicated service. System-specific System types EML Standards 1
Evidence Monitoring service reports covering the period.
Example standards
SCB-MON-01.EML.1Is the email and collaboration platform monitored by a dedicated security service?
Part 2 · Operational practices
STD · 3 controls
Standardisation
Consistent naming, platforms and structures.
SCB-STD-01Systems and devices follow a documented naming convention. Operational System-specific System types NET, RMM Standards 2
Evidence Device and system lists compared with the documented convention.
Example standards
SCB-STD-01.NET.1Do devices follow the naming convention?
SCB-STD-02Hardware and platforms are standardised on approved, supported products. Operational System-specific System types EML, NET Standards 3
Evidence Inventory compared with the approved product list.
Example standards
SCB-STD-02.NET.1Are network devices standardised on the approved platform?
SCB-STD-03Directory, file and collaboration structures follow the organisation's departments. Operational System-specific System types DIR, DMS, EML Standards 5
Evidence Structures compared with the current department list.
Example standards
SCB-STD-03.DIR.2Is there a directory group for each department?
DOC · 1 control
Documentation
Documentation that lets anyone understand and recover the environment.
SCB-DOC-01IT documentation is complete and current: environment summary, server roles, applications, licences and install media. Operational Organisation-wide System types Organisation-wide Standards 5
Evidence Environment summary with its last-updated date; server, application, licence and install-media records.
Example standards
SCB-DOC-01.ORG.5Is the environment summary documented and current?SCB-DOC-01.ORG.4Are install media and licences recorded?
CST · 2 controls
Licensing and cost
Licensing that holds up, and costs that are reviewed.
SCB-CST-01Software and services are properly licensed, with licence details recorded. Operational Organisation-wide System types Organisation-wide Standards 2
Evidence Licence records reconciled with installations and subscriptions.
Example standards
SCB-CST-01.ORG.1Is all office software legitimately licensed?
SCB-CST-02Recurring IT costs and subscriptions are reviewed and right-sized. Operational Organisation-wide System types Organisation-wide Standards 3
Evidence Dated review of recurring costs, with the changes made.
Example standards
SCB-CST-02.ORG.2Are connectivity invoices reviewed?SCB-CST-02.ORG.3Are endpoint licences matched to the number of users?
CAP · 2 controls
Capacity and health
Room to grow, and no errors quietly accumulating.
SCB-CAP-01Systems have capacity headroom and are free of recurring errors. Operational System-specific System types BKP, NET, SRV Standards 5
Evidence Capacity and error reports, with follow-up on anything outstanding.
Example standards
SCB-CAP-01.BKP.2Is backup storage below 80% full?SCB-CAP-01.NET.1Is the internet connection sized for the organisation?
SCB-CAP-02Core network services are correctly configured and kept tidy. Operational System-specific System types DIR, NET Standards 3
Evidence Dated checks of DNS, forwarders and WAN configuration.
Example standards
SCB-CAP-02.DIR.2Are stale DNS records removed?
FAC · 2 controls
Facilities
Server rooms and racks that are labelled, clean and documented.
SCB-FAC-01Server rooms and racks are labelled, clean and photographed. Operational Organisation-wide System types Organisation-wide Standards 6
Evidence Current photos and labelling checks for each server room and rack.
Example standards
SCB-FAC-01.ORG.1Are cables in server rooms labelled?
SCB-FAC-02Equipment runs on the correct electrical supply. Operational Organisation-wide System types Organisation-wide Standards 1
Evidence Electrical supply check against equipment requirements.
Example standards
SCB-FAC-02.ORG.1Is equipment on the electrical supply it needs?
SVC · 2 controls
Service quality
Issues tracked to resolution, and critical services under control.
SCB-SVC-01Open issues are tracked to resolution, with nothing long-standing. Operational Organisation-wide System types Organisation-wide Standards 1
Evidence Open issues list with age and owner; nothing past its target date.
Example standards
SCB-SVC-01.ORG.1Are there any long-standing open issues?
SCB-SVC-02Domain names and DNS zones are under controlled, documented management. Operational Organisation-wide System types Organisation-wide Standards 1
Evidence Registrar and DNS account list with named owners and renewal dates.
Example standards
SCB-SVC-02.ORG.1Are domain names and DNS zones under controlled, documented management?
