Coverage & methodology

Cyber-insurance attestation controls

Covers the macOS controls cyber-insurance renewal questionnaires commonly ask a fleet to attest. It is not any one carrier's form — wording and thresholds differ between insurers, so check a green result here against the questions your own policy actually asks. It evidences the Mac fleet only; servers, network and non-Apple endpoints are out of scope.

What this projection does not cover

There is no single instrument behind this projection — carriers word their questionnaires differently. Beyond that, renewal questionnaires routinely ask about things no Mac's posture can show:

• Multi-factor authentication on business accounts MFA on email, VPN, and admin accounts is an identity-provider control. A device cannot evidence it.
• Backups and tested recovery The posture script does collect whether a Time Machine destination is configured, but we deliberately map no control to it: a configured destination says nothing about whether backups run, are encrypted, or restore. A green check would overstate.
• Third-party endpoint protection (EDR/antivirus) We evidence macOS's built-in protections (Gatekeeper, XProtect). A third-party security agent is invisible to our reads — its presence or health is not something we can attest.
• Email security, security-awareness training, incident-response plans Organizational controls with no device component.
• Everything that is not a Mac Servers, network equipment, Windows and Linux endpoints, and iOS/iPadOS devices (not collected) are out of scope.

CIS macOS Benchmark, Level 1

Covers the Level 1 recommendations a Mac's posture can be read remotely to evidence; recommendations needing local inspection or human judgement are not mapped. Section numbers are CIS macOS 15 (Sequoia) and are verified against the macOS Security Compliance Project — later macOS releases renumber, so read a control ID together with that version. Two Level 2 recommendations are offered as opt-in extras and say so in their titles.

What this projection does not cover

The Level 1 benchmark contains more recommendations than this projection maps. The omissions are of three kinds — not remotely readable, withheld on evidence-quality grounds, or dropped by CIS itself:

• Recommendations needing local inspection or human judgement Anything that requires sitting at the machine, auditing per-user data, or making a judgement call (e.g. reviewing installed profiles' contents) cannot be read remotely and is not mapped.
• 5.2.2 — Password minimum length The signal is collected but deliberately unmapped: pwpolicy misses profile-managed password policies, so the read can report a shorter minimum than the one actually enforced, and the CIS Level 1 objective value is 15 characters. We will not fail a device on a read we know can be wrong.
• 2.3.4.2 — Time Machine volumes encrypted Only “a destination is configured” is readable without Full Disk Access, and CIS's own check passes a Mac with no destination at all. Not mapped rather than mapped weakly.
• Firewall logging CIS removed this recommendation after macOS 14, so it maps to no framework control. Nyvel retains the legacy signal for historical evidence on macOS 12–14; current macOS exposes no supported state check.

Where we deliberately deviate

• Several Level 1 privacy and convenience toggles are opt-in, not default-tracked AirDrop (2.3.1.1), AirPlay Receiver (2.3.1.2), Siri (2.5.2.1), analytics sharing (2.6.3.1), personalized ads (2.6.4), wake-for-network (2.10.3), and login-window names (2.11.4) are Level 1 in CIS but opt-in here. That is a product judgement: reddening a fleet over privacy toggles buries the failures an insurer or auditor cares about. Evidence still accrues, so opting in is instant.
• 3.1 — Security auditing is opt-in auditd is deprecated and off by default since macOS 14; default-tracking it would fail every healthy modern Mac.
• 5.10 — XProtect scanning is opt-in The xprotect CLI the signal reads exists only on macOS 15+, so an older Mac can never evidence it.
• Two Level 2 recommendations are carried as labelled opt-in extras Media Sharing (2.3.3.9) and the login-window banner (5.8).

SOC 2 Common Criteria

Covers the endpoint-device slice of each Common Criterion — a control passing here means the device evidence for that criterion is in place across the fleet, not that the criterion is met. SOC 2 is an audit of the whole control environment, including the policies, people and processes no device signal can show.

What this projection does not cover

A SOC 2 examination covers an organization's whole control environment over a period. This projection maps the endpoint-device slice of four Common Criteria and nothing else:

• CC1–CC5 — Control environment, communication, risk assessment, monitoring, control activities The COSO-derived criteria are about the organization — governance, people, and process. No device signal touches them.
• CC6.x — The rest of logical and physical access User access provisioning and deprovisioning, credential management in your identity provider, physical access to facilities, and data disposal are outside the mapped endpoint slices of CC6.1 and CC6.6.
• CC7.x — Security-event detection, analysis, and incident response CC7.1 is mapped only for its configuration-monitoring slice on endpoints. Event pipelines, alerting, and response are not device posture.
• CC8–CC9 — Change management and vendor risk Organizational processes with no device component.
• The availability, confidentiality, processing-integrity, and privacy categories This projection maps Common Criteria (security) only.

ISO/IEC 27001:2022 Annex A

Covers the endpoint-device slice of the Annex A controls a Mac's posture can evidence. Certification is an audit of the whole ISMS — its scope, risk treatment and the management-system clauses 4–10 — none of which a device reports, and Annex A controls with no device component are not mapped here at all.

What this projection does not cover

ISO/IEC 27001 certification is an audit of the whole ISMS. This projection maps the device slice of 8 of Annex A's 34 technological controls; everything below is explicitly not evidenced:

• Clauses 4–10 — The management system itself Scope, leadership, planning, risk assessment and treatment, support, operation, performance evaluation, internal audit, and improvement — the substance of certification, none of it device-readable.
• A.5 — Organizational controls (37 controls) Policies, roles, supplier relationships, incident management planning, compliance. Not mapped at all.
• A.6 — People controls (8 controls) Screening, terms of employment, awareness and training, disciplinary process. Not mapped at all.
• A.7 — Physical controls (14 controls) Perimeters, entry, clear desk, equipment siting and disposal. Not mapped at all.
• A.8.3 / A.8.4 — Information access restriction; access to source code Access decisions live in your directory and repositories, not in device posture.
• A.8.6 — Capacity management
• A.8.7 — User awareness, malware detection and response, third-party anti-malware The mapped half is prevention kept current — Gatekeeper plus the OS malware-definition updates. A.8.7 also requires that protection be “supported by appropriate user awareness”, which is training, and Nyvel cannot see whether a third-party endpoint-protection tool is installed or healthy. XProtect's own scanning signal is unreliable on current macOS, so it is not used to inflate this control either.
• A.8.10–A.8.12 — Information deletion, data masking, data leakage prevention
• A.8.13 — Information backup The posture script collects whether a Time Machine destination is configured, but we deliberately map no control to it — a configured destination does not evidence working, encrypted, restorable backups.
• A.8.14 — Redundancy of information processing facilities
• A.8.15 / A.8.16 — Logging and monitoring activities Nyvel collects the narrow state of local auditd and, on macOS 12–14, the legacy firewall-logging preference. Those settings do not prove that events are centrally received, retained, searchable, monitored or reviewed, so they are not mapped to these controls.
• A.8.17 — Clock synchronization The signal is collected and mapped under CIS (2.3.2.1) and NIS2 (3.2.6); it is not yet mapped in this projection.
• A.8.18 / A.8.19 — Privileged utility programs; installation of software on operational systems
• A.8.21–A.8.23 — Network services, network segregation, web filtering Network architecture, not endpoint posture.
• A.8.25–A.8.34 — The development-lifecycle controls Secure development, application security requirements, secure coding, security testing, outsourced development, environment separation, change management, test information, audit-test protection.

HIPAA Security Rule (45 CFR part 164, subpart C)

Covers the workstation slice of individual safeguards in 45 CFR §§ 164.308 and 164.312 — cited at implementation-specification level, because the Security Rule's standards are written as policies and procedures that no device can report. A passing control means the workstation evidence for that provision is in place across the fleet; it is not a determination that the provision is met, which an assessor judges on policy, process and non-device scope as well. Where a specification is Addressable, an equivalent documented alternative satisfies the Rule and would read as failing here. Risk analysis, workforce training, sanctions, contingency planning, business-associate agreements, the physical safeguards of § 164.310 and transmission security are outside this projection entirely.

What this projection does not cover

The Security Rule is a two-level instrument: a standard states an outcome, and its implementation specifications state the discrete things a covered entity does about it. Almost every standard is written as “policies and procedures”, which no device can report — so this projection cites specifications wherever they exist, and a standard only where the standard's own text is technical. A passing control means the workstation evidence for that provision is in place, not that an assessor would find the provision met. And where a specification is Addressable (§164.306(d)(3)), a documented equivalent alternative also satisfies the Rule, and would read as failing here. Explicitly not evidenced:

• §164.310(b) — Workstation use Policies specifying a workstation's proper functions, the manner of performing them, and “the physical attributes of the surroundings” it sits in. An earlier version of this projection read the host firewall and the disabled remote-access services off this provision. That was wrong — it is a physical safeguard about documented use and the room the Mac is in — and the mapping was removed rather than narrowed (ADR 0032).
• §164.310 — The physical safeguards generally Facility access controls, device and media controls, disposal, media re-use. None of it is device posture.
• §164.312(e) — Transmission security No collected signal reports anything about ePHI in transit. A host firewall is not evidence of it, and claiming otherwise would repeat the §164.310(b) mistake.
• §164.312(c)(2) — Mechanism to authenticate ePHI Corroborating that records were not altered or destroyed. What we can show is that System Integrity Protection stops the OS and its security mechanisms being modified without authorization — mapped under §164.312(c)(1), and a narrower claim than this one.
• §164.308(a)(1) — The security management process beyond risk management Risk analysis, the sanction policy, and information-system activity review. Only §164.308(a)(1)(ii)(B) is cited, and only for the measures actually implemented on the endpoint: patch currency, the automatic mechanisms maintaining it, and the device being under management.
• §164.308 — The rest of the administrative safeguards Workforce security, training, contingency planning, the periodic evaluation, and business-associate agreements.
• §164.308(a)(5)(ii)(B) — Detection, reporting, and third-party endpoint protection The mapped half is prevention kept current: Gatekeeper plus the OS malware-definition updates. The provision also asks for detecting and reporting malicious software, and Nyvel cannot see whether a third-party endpoint-protection tool is installed, let alone healthy.
• §164.312(b) — Audit controls Nyvel does not collect EDR, SIEM, server or network-logging evidence. Local auditd state and the legacy firewall preference do not prove that activity in systems containing ePHI is recorded and examined, so this provision is not mapped.
• Whether a Mac holds ePHI at all Nyvel reads device configuration, never file contents, so it cannot tell which workstations store or access ePHI — and holds no ePHI itself. Scoping which devices matter is yours.

Annex to Commission Implementing Regulation (EU) 2024/2690 — NIS2 Article 21(2)

Covers the Annex points of Commission Implementing Regulation (EU) 2024/2690 — which implements Article 21(2) of NIS2 — that a Mac's posture can evidence. That Regulation legally binds only eleven digital-infrastructure and digital-provider types; for every other NIS2 entity it is a benchmark, not an obligation. Article 21 also requires supply-chain security, incident handling, business continuity, HR security and governance, which no device signal can evidence.

What this projection does not cover

Two limits before any list: Commission Implementing Regulation (EU) 2024/2690 legally binds only eleven digital-infrastructure and digital-provider entity types — for every other NIS2 entity it is a benchmark, not an obligation. And even where it binds, a passing control means the workstation evidence for that Annex point exists, nothing more. Explicitly not evidenced:

• Annex point 3.2.3(g) — Event logs and logs from security tools Nyvel does not collect EDR, SIEM, server or network-logging evidence. Local auditd state and the legacy macOS firewall preference do not prove that events are off-loaded, retained, searchable, monitored or reviewed. mSCP 2 itself marks native macOS audit off-loading unsupported and expects an enterprise auditing mechanism.
• Annex point 7 — Assessing the effectiveness of risk-management measures Deliberately mapped to no control: point 7 asks for a policy and a measurement procedure, and no device signal can evidence a policy. Continuous per-device evidence is an input to that assessment, not the assessment.
• Art. 21(2) — Supply-chain security, incident handling, business continuity, HR security, governance Most of what Article 21 demands is organizational, with personal management-body liability attached (Art. 20). None of it is device posture.
• Art. 23 — Incident notification duties The 24-hour early warning and subsequent reports are legal obligations on the entity; no product makes them happen.
• Signals with no honest home in the Annex The privacy toggles (Siri, analytics, personalized ads) evidence no Annex point and are not stretched onto one.