# RemotePower — security control mapping (SOC 2 / ISO 27001)

> **What this is:** a mapping of RemotePower's built-in capabilities to the common
> framework control areas auditors ask about — SOC 2 (Trust Services Criteria) and
> ISO/IEC 27001:2022 (Annex A). **What it is not:** a certification, an attestation,
> or a claim that deploying RemotePower makes *you* compliant. Compliance is a
> property of your whole organisation and operating procedures; RemotePower provides
> *technical controls and evidence* that support several criteria. Items marked
> **(operator)** depend on how you configure and run it.

Many of these controls are **opt-in** — see the linked feature docs and
`CHANGELOG.md` for how to enable each.

## Access control & identity

| Capability | SOC 2 | ISO 27001:2022 |
|---|---|---|
| RBAC — admin/viewer/auditor/finance + custom roles scoped to groups/tags/sites | CC6.1, CC6.3 | A.5.15, A.8.2, A.8.3 |
| MFA — TOTP + WebAuthn/passkeys; per-role MFA **enforcement** | CC6.1 | A.5.17, A.8.5 |
| SSO — OIDC / SAML 2.0 / LDAP + SCIM 2.0 provisioning; group→role matrix; SSO-only mode | CC6.1, CC6.2, CC6.3 | A.5.16, A.5.18 |
| Password policy — length / classes / HaveIBeenPwned breach check **(operator)** | CC6.1 | A.5.17 |
| Joiner/mover/leaver — SCIM deprovision revokes access + live sessions at once | CC6.2, CC6.3 | A.5.16, A.5.18 |
| Session controls — concurrent-session caps, idle timeout, active-session revoke | CC6.1 | A.8.5 |
| Service accounts — API keys hashed at rest, per-key device **scope**, source-IP allowlist, rate limit, expiry | CC6.1 | A.5.16, A.8.2 |
| Privileged access — two-person break-glass credential reveal (audited) | CC6.1 | A.8.2, A.8.18 |
| Remote administrative access — the compliance report attests resolved **sshd** posture per host — a root **password**, password authentication or empty passwords fail. `PermitRootLogin prohibit-password` (root by key, and Debian's default) is reported as a note on the pass rather than a failure, because a control that fires on every stock Debian host gets ignored. Mapped to PCI 2.2.7, SOC 2 CC6.1 and Essential Eight E8-5; hosts that do not report sshd are `not assessed`, never `pass` *(v7.0.0)* | CC6.1, CC6.6 | A.5.15, A.8.2, A.8.5 |
| governance switches step-up gated — changing four-eyes approval, MFA-required roles, the WORM sink, audit retention/forwarding, the IP allowlist, SSO-only, tenancy or read-only mode requires the admin to re-verify their password/TOTP, and is audit-logged by name *(v6.4.2)* | CC6.1, CC8.1 | A.5.15, A.8.2, A.8.15 |

## Cryptography & data protection

| Capability | SOC 2 | ISO 27001:2022 |
|---|---|---|
| Encryption at rest — AES-256-GCM DR backups; opt-in config-secret encryption (`RP_CONFIG_KEY`) | CC6.7 | A.8.24 |
| Secrets sourcing — backup/config keys from env **or** an external command (Vault/KMS) | CC6.7 | A.8.24 |
| Credentials at rest — API keys, device tokens, enrolment tokens stored as SHA-256 hashes | CC6.1 | A.8.24 |
| Encryption in transit — TLS 1.2 floor; mutual-TLS agent authentication; CSP / HSTS | CC6.7 | A.8.20, A.8.24 |

## Logging, monitoring & evidence

| Capability | SOC 2 | ISO 27001:2022 |
|---|---|---|
| Audit log — hash-chained (tamper-evident); append-only **WORM** sink option | CC7.2, CC7.3 | A.8.15, A.5.28 |
| Config-change auditing — every settings save records the changed keys | CC8.1 | A.8.32 |
| Centralised logging — webhook/SIEM forwarding, syslog ingest, structured JSON logs + correlation/trace IDs | CC7.2 | A.8.15, A.8.16 |
| Monitoring & alerting — fleet health, service/log/metric alerts, escalation tiers, SLO + error budgets | CC7.1, CC7.2 | A.8.16 |
| Signed evidence — compliance evidence pack + audit-archive export carry HMAC signatures; key rotation | CC7.3 | A.5.28 |
| Self-observability — control-plane uptime, slow-handler ring, client-error beacon | CC7.2 | A.8.16 |

## Vulnerability & configuration management

| Capability | SOC 2 | ISO 27001:2022 |
|---|---|---|
| Vulnerability management — CVE scanning with KEV/EPSS prioritisation; patch status + alerts | CC7.1 | A.8.8 |
| Secure configuration — drift detection + remediation; CIS/posture checks; **OpenSCAP/USG benchmark results scored as a control** *(v7.0.3)*; firewall/fail2ban visibility | CC7.1 | A.8.9 |
| Change management — staged/health-gated rollouts with rollback; audited command queue | CC8.1 | A.8.32 |
| Supply chain — fleet + control-plane SBOM (CycloneDX); SLSA build provenance on release images | CC7.1 | A.5.23, A.8.30 |

## Resilience & operations

| Capability | SOC 2 | ISO 27001:2022 |
|---|---|---|
| Backup & DR — encrypted controller backup, off-host mirroring, **test-restore** verification of both the local and the off-host copy *(v7.0.0; before that the drill verified the local archive only)* | A1.2 | A.8.13, A.5.30 |
| Availability — agent/agentless monitoring, maintenance mode/windows, webhook DLQ + replay | A1.1, A1.2 | A.5.30, A.8.16 |
| Boundary protection — SSRF guards on all outbound, per-IP/login rate limits, IP allowlist, CSP | CC6.6 | A.8.20, A.8.23 |
| Multi-tenant isolation — RBAC-scoped soft tenancy (group/tag/site); optional **hard multi-tenancy** (`tenancy_enforced`) with optional Postgres **row-level security** (`tenancy_rls`) **(operator)** | CC6.1 | A.5.15, A.8.2 |

## Data-subject rights (GDPR Art. 15 / 17) *(v6.4.2)*

RemotePower holds personal data about **people**, not only about hosts:
operator accounts and avatars, the Contacts directory (name / role / company /
email / phone / notes), ticket authors and assignees, ticket comment authors,
time-billing entries, and audit `actor` fields. (This is distinct from the
[PII scanner](pii-scan.md), which finds regulated data on the hosts you manage.)

| capability | SOC 2 | ISO 27001:2022 |
|---|---|---|
| subject-access report — enumerate every record naming a person (`GET /api/privacy/subject?who=&email=`); admin + auditor, itself audited | CC6.1 | A.5.34 |
| erasure — remove the account, avatar, sessions and contact record (`POST /api/privacy/erase`), reporting exactly what is retained | P4.2 | A.5.34, A.8.10 |
| deletion hygiene — deleting a user now also unlinks the avatar and prunes their sessions | — | A.8.10 |

**What is erasable, and what is not.** The report and the erasure response both
say so explicitly rather than implying a clean sweep:

- **Erasable:** the user account, the avatar file, the session rows, and the
  Contacts record.
- **Retained —** hash-chained **audit-log** entries (rewriting one
  destroys the tamper-evidence that makes the log evidence at all; retention is
  the lawful position under Art. 17(3)(b)/(e)), plus **ticket authorship**,
  **comment authorship** and **time entries**, which are business and billing
  records.
- The **erasure itself is audit-logged and names the subject** — that entry is
  the evidence the request was honoured, and is what a DPO will ask for.
- **Backups taken before the erasure still contain the data.** Rotate or
  re-take them if your retention policy requires it.

RemotePower provides the technical means; deciding what your lawful basis and
retention periods are remains yours.

## Operator responsibilities (not provided by the software)

RemotePower supplies technical controls + evidence; **you** still own: the control
*environment* and policies (CC1), risk assessment (CC3), vendor/personnel management
(CC9 / A.5.19, A.6), physical security of your hosts (A.7), and the procedures that
turn these features into operating controls (reviewing the audit log, acting on
alerts, running restore drills, rotating keys). Enable the opt-in controls above,
forward the audit log + alerts to your SIEM, and retain the signed evidence exports
as your audit artifacts.

**Encryption at rest of the control-plane host itself** (A.8.24 / CC6.7) is yours
too: RemotePower encrypts the CMDB vault and — with `RP_CONFIG_KEY` — config
secrets, but device tokens, API-key hashes and DR backups live in `RP_DATA_DIR` on
whatever volume you gave it. **Settings → Security posture** grades that volume
(v7.0.0) so the gap is visible rather than assumed; inside a container it reports
"cannot be determined", which is an instruction to check the host, not a pass.

Three of those responsibilities are procedures rather than settings, and each now
has a page saying exactly which RemotePower surface answers which part of it —
because "the operator owns this" is not useful guidance on its own:

- **[access-review.md](access-review.md)** — the quarterly recertification
  (CC6.2/CC6.3, A.5.18): which field answers which question, and what the product
  will not decide for you.
- **[incident-response.md](incident-response.md)** — the RemotePower half of an IR
  plan (CC7.3/CC7.4, A.5.24–A.5.26), including the case where the control plane
  itself is the suspect.
- **[data-retention.md](data-retention.md)** — what each store keeps and for how
  long (A.5.33, A.8.10). Worth reading before you publish a retention period:
  most stores default to keeping everything forever.

> Framework control IDs are indicative and current as of the 2022 ISO revision +
> the SOC 2 2017 TSC; map to your auditor's current criteria.

## In-app Compliance page — verdicts you can back up *(v6.4.0)*

The **Compliance** page scores a live control checklist from data the fleet
already reports, across **PCI DSS, HIPAA, SOC 2, ACSC Essential Eight and
SMB1001:2026** (pick the frameworks with the checkboxes). As of v6.4.2 the
checklist assesses **host firewall state** (PCI 1.2.1 — previously declined as
unassessable), **anti-malware / protection from malicious software** from the
actual AV posture rather than patch counts (PCI 5.2.1, HIPAA
164.308(a)(5)(ii)(B)), and **encryption at rest** on managed hosts —
BitLocker / FileVault / LUKS (PCI 3.5.1, HIPAA 164.312(a)(2)(iv)).

**v7.0.3 turns four more collected sources into evidence.** Each had a page or
an alert path for several releases and reached the checklist nowhere:

| Source | Backs |
|---|---|
| OpenSCAP / USG benchmark results | Configuration baselines — PCI 2.2.1, SOC 2 CC7.1c, SMB1001 S-config |
| The privileged-command (sudo) trail | Logging of privileged actions — PCI 10.2.1.2, SOC 2 CC6.3, E8-5c |
| The regulated-data inventory | Data minimisation — PCI 3.2.1, SOC 2 C1.1, SMB1001 S-data |
| DMARC / SPF / DKIM posture | Anti-phishing — PCI 5.4.1, SMB1001 S-email |

Two of these are worth reading closely. The privileged-command control attests
that sudo and doas use is being **recorded**, which is what an audit-trail
requirement asks for — it is not a judgement about whether a given command was
appropriate, and a host that ran no sudo command is not a finding. And a domain
you have added but never checked reads **Not assessed**, not Pass: typing a
domain into the DMARC page is not evidence about it.

Every control lands on one of four verdicts:

- **Pass** — observed state satisfies the control.
- **Fail** — observed state violates it, with the offending hosts as evidence.
- **Not assessed** (amber) — the control *is* assessable, but its capable
  source hasn't run yet: no host has reported package status, no CVE scan is on
  record, no TLS endpoint is monitored, no account baseline exists. This is a
  **monitoring blind spot** — shown, never a silent green, so a
  control does not read Pass just because its offenders list happens to be
  empty.
- **N/A** (grey) — RemotePower *structurally* cannot assess this control at all
  (Essential Eight application control / macro policy / user hardening; SMB1001
  training / IR plan). Disclosed rather than hidden — the report shows its own
  gaps instead of quietly dropping the row.

"Not assessed" (a gap you can close by turning on monitoring) is rendered
distinctly from "N/A" (a gap RemotePower can't close) so you can act on the
right one.

The framework **score is `pass / (pass + fail)`** and ignores both Not-assessed
and N/A, so
"we haven't measured it" can never inflate the number. This is an audit-prep
aid, not a formal attestation — but a green you see is a green the tool can
defend.