ISO 27001 access controls for SaaS accounts, and the evidence auditors look for

ISO/IEC 27001:2022 is the current edition of the ISO standard for information security management systems, and its Annex A lists the controls an organization compares its own against. NIST publishes a free crosswalk from its SP 800-53 controls to the 2022 edition. It maps NIST’s controls on accounts, least privilege and passwords to A.5.15, A.5.16, A.5.17, A.5.18 and A.8.2, among others. For the SaaS apps your team uses, those controls cover who may use each app, how accounts are created and removed, how passwords are handled, and who holds admin rights. What an auditor sees is your Statement of Applicability and the records that show you do what it says. What ISO 27001 is and how certification works is in What is ISO 27001?

Where to read what the controls say

ISO sells the standard. Its page lists ISO/IEC 27001:2022 as the third edition, published in October 2022, with one amendment (Amendment 1:2024, on climate action). The control guidance sits in a companion standard, ISO/IEC 27002:2022, which ISO says you can’t be certified to.

NIST’s crosswalk is free. It links each SP 800-53 control to the ISO numbers that cover similar ground, and SP 800-53 is free to read. So this article describes what the NIST controls ask for and names the ISO numbers NIST maps them to. It doesn’t quote or paraphrase ISO’s control text. Treat a mapped NIST control as a pointer to where to look in your copy of the standard.

Annex A is a reference list, not a checklist

The ISO/IEC 27001 Auditing Practices Group has published notes on how auditors and auditees should read Annex A. They were issued through a working group of ISO/IEC JTC 1/SC 27, the committee ISO lists for the standard, and they say ISO hasn’t endorsed them. They explain that clause 6.1.3 c) asks you to compare the controls your risk assessment produced with Annex A, so you catch any you missed. They also say the requirements in Annex A apply only if you decide a control is relevant.

Your Statement of Applicability (SoA) records the result. Per the notes, it lists the controls you need, why you need them, whether each one is in place, and why you left out any Annex A control. The controls in it don’t have to use ISO’s wording. You can write them as statements of what you do, such as “we remove a leaver’s access to every SaaS app within two business days.”

That choice matters for SaaS. The notes warn about copying Annex A text as your control. If you then don’t do what it says, an auditor has plenty of room to record a nonconformity, a formal finding that you don’t meet the standard. A control written to match your actual SaaS routine is easier to back with records.

The five account controls, applied to SaaS

The table pairs each ISO number with the main SP 800-53 controls NIST maps to it. The last two columns are this article’s reading for SaaS, not ISO’s text.

AC-2 carries the most weight here, since NIST maps it to A.5.16, A.5.18 and A.8.2 at once. It asks you to define which account types are allowed, require approvals to create accounts, and monitor how they’re used. It also asks you to tell account managers within a set time when a user leaves or changes role, and to review accounts at a frequency you choose.

For admin rights, AC-6 has enhancements that restrict privileged accounts to defined people or roles (AC-6(5)) and log the use of privileged functions (AC-6(9)). In a SaaS app, the admin is whoever can add users, change roles or change security settings. Keep a short list of who holds that role in each app and why. Which accounts count as privileged is in What is a privileged account?

Shared logins under these controls

A shared account is one login that several people use. SP 800-53 lists shared and group accounts among the account types an organization may choose to prohibit because of increased risk, and AC-2(9) points to the lack of accountability. Where you allow one, AC-2k and IA-5i both ask for the password to change when someone leaves the group.

The record is the harder part. NIST maps AU-3, on the content of audit records, to A.8.15. AU-3 asks that a record show what happened, when, where, its source, its outcome, and who was involved. An app’s sign-in history for a shared login names the account, so five people show up as one. To tie each use to a person, either give each person their own user, or put something in front of the login that records who signed in.

What to show the auditor

Start with the SoA entries for these controls, written as what your company actually does with SaaS accounts. Then have records ready that match each entry:

1. A list of SaaS apps in scope, each with a named owner.
2. For each app, the current users, and for each shared login, who may use it and who knows the password.
3. Requests and approvals for new users and role changes, with dates.
4. Removal records for people who left or changed roles, with dates.
5. A list of admins per app and the reason each one needs the role.
6. Review records showing you checked users and admins on your schedule (AC-2j, AC-6(7)).
7. Sign-in records that name a person for each use, including on shared logins.

If a vendor’s people work in your accounts, the supplier controls apply as well. That case is covered in Which ISO 27001 controls apply when a vendor uses your accounts.