{
  "format": "complianceone.secure-configuration-guide.v1",
  "rule": "SCG-CSO-RSC",
  "rulesDataset": {
    "dataset": "fedramp-consolidated-rules.json",
    "version": "2026.09.13.02",
    "url": "https://github.com/FedRAMP/rules"
  },
  "title": "ComplianceONE Secure Configuration Guide",
  "introduction": "This guide tells an agency how to configure its ComplianceONE tenant securely. It covers the accounts that control the whole tenant, the settings only those accounts can change, and the settings other privileged roles can change, with the security effect of each (SCG-CSO-RSC). It describes ComplianceONE as it runs in Microsoft Azure Government.\n\nEnforced in Azure Government. Everything this guide describes as a default or a restriction is enforced in the ComplianceONE production instance in Microsoft Azure Government (US Gov Virginia), which has served agencies since 7 October 2026: the sign-in and session defaults in section 3, the secure defaults in section 7, and the limits on who can change each setting in sections 4 to 6. Tenants cannot turn these off or weaken them. The platform configuration that holds them in place is PlatformOne's and is assessed under the Key Security Indicators in ComplianceONE's Security Decision Record. Section 9 lists the further security settings the production instance enforces.\n\nHow accounts are named in ComplianceONE. Access is granted by security roles. A tenant is created with 14 built-in roles copied from ComplianceONE's catalog of 313 permissions; tenants can clone and edit them or create their own.\n\n- Top-level administrative account: any user who holds the Organization Admin role (role key org_admin). That role carries an organization-wide administrator flag that grants every tenant permission except two impersonation permissions, which it holds explicitly instead. The first user of a new tenant is assigned Organization Admin when PlatformOne provisions the tenant.\n- Treat as top-level: Internal Setup (role key internal). It cannot read compliance records, but it can assign any role, including Organization Admin, to any user, including itself. Anyone holding the security_assignment:create permission, in any role, is in the same position.\n- Privileged accounts: Internal Setup, Trust Center Admin (tc_admin), Compliance Manager, ISSO (Security Reviewer), Authorizing Official, Auditor, and any custom role that includes user, role, permission, group, security_assignment, security, export_destination, trust_center_settings or trust_center_page:publish permissions.\n- Platform Super Admin is a PlatformOne operator role. It is never copied into a tenant and is not used for agency administration.\n\nDefaults that apply to every account. Sign-in is a password plus a six-digit one-time code sent to the account's email address; the code expires after 5 minutes and allows 5 attempts. Access tokens last 15 minutes. Refresh tokens rotate on every use, and reusing an old one revokes the whole session. Eight failed sign-ins for one email address within 15 minutes lock that address out for the rest of the window. Passwords are stored as Argon2id hashes. Tenants cannot change these settings.",
  "serviceName": "ComplianceONE",
  "sections": [
    {
      "key": "top-level-account-lifecycle",
      "ordinal": 1,
      "tier": "required",
      "prompt": "Instructions on how to securely access, configure, operate, and decommission top-level administrative accounts that control enterprise access to the entire cloud service offering.",
      "body": "Access\n1. Sign in at the ComplianceONE address your agency was given, with your email, password and the emailed one-time code. Use an agency-managed mailbox: the one-time code is your second factor, so whoever controls the mailbox controls the account.\n2. Change the temporary password PlatformOne or another administrator sent you the first time you sign in. ComplianceONE forces the change: no other action is allowed until the temporary password is replaced.\n3. Sign out when you finish (this revokes the session). Do not share accounts; every action is recorded under the signed-in user.\n\nConfigure\n1. Keep at least two and no more than three Organization Admins, each a named person. One admin is a single point of failure; more than three widens the blast radius of a stolen mailbox.\n2. Give Organization Admins a separate everyday account with a lesser role (for example Compliance Manager) for routine work, and use the admin account only for administration.\n3. Treat Internal Setup the same as Organization Admin (see the introduction): assign it only to people you would trust with Organization Admin, and review it at the same cadence.\n4. Decide whether your Organization Admins need impersonation. The built-in Organization Admin role holds security:impersonate and security:view_impersonation_logs explicitly. If you do not use impersonation, clone the role without security:impersonate and assign the clone instead.\n5. Assign roles through groups where you can, so that removing someone from a group removes the access.\n\nOperate\n1. Review the audit log at least monthly (permission audit_log:read). It records sign-ins (succeeded, failed, blocked), sign-outs, password changes, session revocations, user invitations and changes, role and permission changes, role assignments and revocations, team changes, impersonation and framework uninstall or sync. Export it for your own records with the audit-log export.\n2. Review role assignments at least quarterly, and check the separation-of-duties matrix for risky role combinations. ComplianceONE blocks a role assignment that creates a separation-of-duties conflict.\n3. If you use impersonation, review the impersonation log and run Verify chain; the log is hash-chained, so a gap or edit shows up.\n4. When an administrator leaves or changes job, act the same day (Decommission, below).\n\nDecommission\n1. Revoke the person's Organization Admin (or Internal Setup) assignment first, so the account loses administrative rights at the next token refresh.\n2. Then deactivate the user (reversible) or remove the user (permanent). Both revoke every session at once. An access token already issued stays valid for up to 15 minutes, so for a hostile departure revoke first, then deactivate, then confirm in the audit log.\n3. Do not leave the tenant with fewer than two Organization Admins; assign a replacement before you remove the last-but-one.\n4. To close the whole tenant, contact PlatformOne (security@platformoneinc.com). Archiving or deleting a tenant is a PlatformOne operator action. Tenant deletion removes every record type and every file. An Organization Admin can also request deletion from within the tenant (section 9)."
    },
    {
      "key": "top-level-account-settings",
      "ordinal": 2,
      "tier": "required",
      "prompt": "Explanations of security-related settings that can be operated only by top-level administrative accounts and their security implications.",
      "body": "These settings can be changed only by an Organization Admin among the built-in roles (Internal Setup can reach them by assigning itself Organization Admin; see the introduction).\n\n- Custom permissions (permission:create, permission:update, permission:deactivate). Defines new permission keys or changes existing ones. Implication: a changed permission changes what every role holding it can do; review before and after.\n- Impersonation (security:impersonate, security:view_impersonation_logs). Lets an admin act as another user to troubleshoot. ComplianceONE blocks impersonating yourself, an inactive user or another Organization Admin, and blocks nested impersonation; start and end are logged to the hash-chained impersonation log and the audit log. Implication: actions taken while impersonating land on the other user's records; keep the permission only if you need it.\n- Organization settings (org_settings:manage). Tenant-level settings and feature knobs. Implication: changes affect every user in the tenant; changes to the organization record are written to the audit log.\n- Connect, change or disconnect integrations. Built-in roles other than Organization Admin hold integration:read only. Integrations read from your own security and IT tools with credentials you issue. Implication: the credential you enter decides what ComplianceONE can read from that tool; issue read-only credentials, and revoke them in the tool when you disconnect. Integration changes are written to the audit log.\n- Uninstall a framework (framework:delete). Implication: uninstalling deletes the framework's policies, procedures, risks and POA&Ms in your tenant. No other built-in role holds it, by design.\n- Everything any privileged role can do (next section), because the Organization Admin flag includes those permissions.\n\nSettings that are PlatformOne's, not yours. The subscription access controls (whether the tenant is enabled, full or temporary access, expiry date, which frameworks are licensed) and the tenant's lifecycle status are set by PlatformOne. ComplianceONE blocks every tenant user, including Organization Admin and Internal Setup, from changing them, and records any attempt in the audit log."
    },
    {
      "key": "privileged-account-settings",
      "ordinal": 3,
      "tier": "recommended",
      "prompt": "Explanations of security-related settings that can be operated only by privileged accounts and their security implications.",
      "body": "- Users (user:invite, update, activate, deactivate, remove; held by Internal Setup). Invited users receive a temporary password by email; invitations expire, and the invited user must accept before the account is usable. Implication: invite only to agency mailboxes, and revoke any invitation that was sent in error. Seat limits apply.\n- Roles and role assignments (role:create, clone, update, delete, assign_permissions; security_assignment:create and revoke; group:*; held by Internal Setup). Implication: ComplianceONE blocks a holder of security_assignment:create from assigning Organization Admin unless they already hold it. A role assignment can carry an expiry date, and ComplianceONE removes the access when it passes. Role changes take effect at the user's next token refresh (within 15 minutes).\n- Separation-of-duties matrix (role:read or security:list_roles). Reports role-by-module risk and conflicting role pairs. Implication: it is a report, not a control; act on what it shows.\n- Audit log (audit_log:read; Internal Setup, Compliance Manager, Auditor). Read and export the tenant audit log. Implication: the log contains user email addresses and source addresses; limit who can export it.\n- Trust Center (Trust Center Admin). Publish and unpublish the Trust Center, add and remove documents, mark documents public or private, change which sections show, and approve or deny access requests (approval sends an access link that expires; the approver sets the date and a default applies when none is chosen). Trust Center Editor can draft and upload but not publish. Implication: publishing makes content visible outside your tenant; Trust Center changes are written to the audit log; keep publishing with a small named group.\n- Export destinations (export_destination:*; Compliance Manager). Connects Google Drive or SharePoint so that reports are delivered there. Implication: the credential you store lets ComplianceONE write to that location; use a dedicated folder and a narrowly scoped credential.\n- Data sensitivity log (data_sensitivity:read, resolve; Compliance Manager). ComplianceONE scans text for patterns that look like PII, PHI, CUI, FCI or government identifiers and warns before saving; a user can acknowledge and save anyway, which is logged. Implication: the scan warns and logs, it does not block; review the log.\n- Review alert settings (review_alert_settings:update; Compliance Manager). Warning window before a policy, procedure or plan review is due (default 30 days, 1 to 90) and channels (in-app on, email off by default). Implication: turn email on so that reviews are not missed.\n- Frameworks (framework:import; Internal Setup and Compliance Manager). Installs framework content into the tenant.\n- AI credits (ai_credits:read; ai_credits:purchase for Compliance Manager). AI drafting draws on a monthly credit grant. Implication: AI drafts are suggestions; every AI feature, including bulk control-statement generation and plan generation, holds its output for a person to review before it is saved, and an Organization Admin can turn AI drafting off for the tenant.\n- Personal MCP access tokens (where your plan includes MCP access). Each user creates and revokes only their own tokens; a token acts with that user's permissions, is checked against the user's status on every call, and can be set to expire after 7 to 365 days (90 by default) or never. Implication: choose an expiry, never \"never\"; an administrator can set the tenant's maximum token expiry, revoke another user's tokens, and turn MCP access off for the tenant."
    }
  ],
  "version": 1,
  "publishedAt": "2026-10-07",
  "requiredSectionsComplete": true
}