Loading

Running a Security Check-up

The Security Check-up is a read-only report of every security-relevant setting on your installation, gathered on one screen. Use it before an audit such as Cyber Essentials Plus, after an upgrade, or whenever you need to show somebody how the platform is actually configured rather than how you remember configuring it.

Where to find it

Architect Panel → Security:

  • Security Check-up — the full report, section by section

Architect Panel → Configuration:

  • Site Settings — where most of the settings the report reads are changed

The Status Panel button in the Architect Panel header also opens a Security Configuration card, which shows how many settings need review and has its own Security Check-up button. The card and the report are worked out by the same checks, so their numbers always agree.

What the report covers

The report is divided into thirteen sections, each with a contents button at the top that jumps to it and shows how many findings in it need attention:

  • Authentication methods: which sign-in methods are switched on, and each Active Directory domain, Azure AD tenant and SAML provider.
  • Multi-factor authentication: whether 2FA is available, whether it is enforced and for whom, which methods are offered, and how many enabled local accounts have an authenticator app.
  • Password policy: length, composition, common-password and username checks, history and expiry.
  • Brute-force protection: blocking by IP address and by account, what is blocked now, and failed sign-ins in the last seven days.
  • Sessions: the idle timeout, cookie flags, database session checks and the timeout warning.
  • Accounts and access control: accounts with administrative or architect access, dormant accounts and disabled accounts.
  • Data protection, Audit and logging, Integrations and exposure, Security headers, HTTPS certificate, TLS and ciphers and Platform and PHP: encryption at rest, file storage, the audit chain, API keys, response headers, the certificate the site presents and the server software.

Each section is a table with four columns: Setting, This installation (the value actually in force), Assessment and Notes.

The five assessments

  • OK: the setting meets the usual expectation.
  • Review: acceptable in some circumstances, but worth a deliberate decision.
  • Action needed: a gap an assessor would record against you.
  • Not implemented: the platform has no setting for this control, or has one it does not enforce. These are stated plainly rather than shown as configured, and they are not counted as something you can clear.
  • For information: context such as counts and current values, not a finding.

Running a check-up

  1. Open Security Check-up. The header confirms which site the report describes and the date and time it was produced.
  2. Read the five summary tiles at the top. Each shows how many findings carry that assessment, and each is also a filter: untick OK and For information to leave only the findings that need a decision. A note under the tiles says how many findings the filter is hiding, with a Show all button.
  3. Work through the sections with the most findings first, using the contents buttons.
  4. Where a finding counts something (accounts, blocked addresses, encrypted fields), use its button, such as View accounts or View blocked addresses, to list the entries behind the number. Long lists show the first 200 and say so.
  5. Where a finding names the screen that changes it, the button in the Notes column opens that screen directly. Findings marked Set in config/config.php are held in the server configuration and are changed by your hosting administrator.
  6. Use Print this report to keep a dated copy as evidence. The printout includes the date and the site address from the header.

Nothing on the screen changes anything

The report only reads. Opening it, filtering it and listing entries alter no setting, so it is safe to give it to an auditor or a new administrator. To change a finding, follow its button to the screen that owns the setting, save there, and reopen the report to confirm the assessment has moved.

What goes wrong

  • A finding still shows the old value after you saved. Reopen the report from the panel rather than relying on the copy already open; it is assembled when the screen loads.
  • A setting is switched on but marked Review. Read the note. Some settings only take effect when another one is on; the report calls these "Enabled, but INERT" rather than letting them pass.
  • "That list is not available on this installation." The data that list reads from is not installed on your site, usually because the feature it belongs to has not been set up.

Worked example

An organisation preparing for Cyber Essentials Plus opens the Security Check-up and filters it down to Action needed and Review. It finds four items: 2FA is available but not enforced, blocking by account is disabled, the minimum password length is 8 with no common-password check, and 23 enabled accounts have not signed in for 90 days. The administrator follows each Site Settings button in turn, uses View accounts to export the dormant list for managers to confirm, and prints the report before and after as evidence of the change.

Recommendations

  • Run it after every upgrade, not only before audits, because new settings arrive with new releases.
  • Filter to Action needed and Review to get a working list, then show all again before printing.
  • Do not record a Not implemented control as present in an audit return; the report says so for a reason.
  • Keep the printed copies with your audit evidence, dated.
  • Use the entry lists for dormant and privileged accounts as the starting point of an access review.