✅ ISO 27001 and SOC 2

ISO 27001 and SOC 2 for Linux servers: what auditors look for, and the evidence to hand them
ISO/IEC 27001:2022: an international standard for an information security management system (ISMS), certified by an accredited body      SOC 2: an attestation report by a CPA firm against the AICPA Trust Services Criteria      Both: about running a security PROGRAM, not about a specific Linux setting

Neither framework tells you "set PermitRootLogin to no". They ask whether you have identified your risks, chosen controls, applied them consistently and can prove it. Linux hardening is how you satisfy many of the technical controls, and the evidence you keep (configuration standard, scan reports, tickets, logs) is what auditors examine. This sheet maps the controls that touch servers to Linux practice and lists the evidence to keep. It is a guide, not audit advice: your auditor decides what is in scope.
Facts checked 2026-09-29.

   - The standard has management clauses (scope, risk assessment, policy, internal audit, management review) plus Annex A, a list of 93 controls in four themes: Organisational (37), People (8), Physical (14) and Technological (34). The 2022 edition introduced 11 new controls.
   - The transition from the 2013 edition ended on 31 October 2025: certificates that had not moved to 2022 expired. If you are certified now, you are on 2022.
   - You produce a Statement of Applicability (SoA) saying which Annex A controls you use and why, and the certification body audits it. Annex A controls are chosen from your risk assessment: they are not a checklist you must all tick.
   - ISO/IEC 27002 gives the guidance for each control.

Control                                          What auditors want to see                          Linux practice
8.2   Privileged access rights                   Admin rights are restricted and approved           Named sudo groups, no shared root, periodic review
8.3   Information access restriction             Access limited per policy                          File permissions, groups, SELinux/AppArmor
8.5   Secure authentication                      Strong, appropriate authentication                 SSH keys, MFA for admins, lockout, password quality
8.7   Protection against malware                 Controls suited to the risk                        Endpoint agent or ClamAV where suitable, patching, package signing
8.8   Management of technical vulnerabilities    Vulnerabilities found and fixed on a schedule      Patch process with dates, scheduled scans, advisory subscriptions
8.9   Configuration management                   A documented baseline, applied and monitored       A CIS or STIG baseline, scans, drift detection, config in version control
8.13  Information backup                         Backups made and restores tested                   Encrypted off-site backups, restore-test records
8.15  Logging                                    Logs produced, protected and reviewed              auditd, journald, a central log server, retention policy
8.16  Monitoring activities                      Anomalies are detected and acted on                Alerts on failed logins, sudo use and service changes; a SIEM or log tool
8.17  Clock synchronisation                      Clocks agree across systems                        chrony / NTP to a common source
8.19  Installation of software on operational systems   Controlled change to software           Approved repositories, package signing, change tickets
8.20  Networks security                          Networks are protected                             Host firewalls, segmentation, restricted admin paths
8.24  Use of cryptography                        A policy for keys and algorithms                   TLS 1.2+, LUKS at rest, key management and rotation
8.32  Change management                          Changes are reviewed, tested and recorded          Pull requests, tickets, maintenance windows
Numbers follow ISO/IEC 27001:2022 Annex A. Your Statement of Applicability decides which ones you claim.

   - SOC 2 is a report from an independent CPA firm on your controls, against the AICPA Trust Services Criteria. The five categories are Security (the required one, also called the Common Criteria), Availability, Processing Integrity, Confidentiality and Privacy. You choose which categories are in scope: most companies start with Security.
   - The Common Criteria are numbered CC1 to CC9: CC1 Control Environment, CC2 Communication and Information, CC3 Risk Assessment, CC4 Monitoring Activities, CC5 Control Activities, CC6 Logical and Physical Access Controls, CC7 System Operations, CC8 Change Management, CC9 Risk Mitigation.
   - Type I reports describe whether controls are designed properly at a point in time. Type II reports test whether they operated effectively over a period (commonly three to twelve months), and are what customers usually ask for.
   - SOC 2 is not a certification. You get a report with an opinion, and you choose to share it under NDA.

CC6.1   Logical access security measures         SSH keys, MFA, least-privilege groups, no shared accounts
CC6.2   Registering and authorising users        A ticket to create access and another to remove it (joiners and leavers)
CC6.3   Role-based access and least privilege   Sudo groups by role, periodic access reviews
CC6.6   Boundary protection                      Host firewalls, security groups, segmentation
CC6.7   Restricting data transmission            TLS, SSH, VPN
CC6.8   Preventing or detecting unauthorised or malicious software   Patching, package signing, malware protection, file integrity monitoring
CC7.1   Detecting configuration changes and vulnerabilities         Baseline scans, drift detection, vulnerability scans
CC7.2   Monitoring for anomalies                 Central logs, alerts, log review
CC7.3 to CC7.5   Incident response and recovery  Runbooks, ticketed incidents, tested backups and recovery
CC8.1   Change management                        Reviewed and tested changes, approvals, rollback plans
The criteria are goals and each company chooses its own controls and shows they work. Criteria numbers are from the AICPA Trust Services Criteria: check the current version with your auditor.

   1. Choose and document a configuration standard (for example CIS Level 1 Server for your OS version). See the CIS sheet.
   2. Automate it: images, Ansible or cloud-init, so every server starts the same and drift shows up.
   3. Scan on a schedule (OpenSCAP, USG, Lynis: see the scanning-tools sheet) and save each report with its date.
   4. Patch on a documented schedule, reboot when kernels change, and keep the records.
   5. Centralise logs, set retention, and record who reviews them and how often.
   6. Manage access through tickets: request, approval, grant, review and removal, with dates.
   7. Encrypt data at rest and in transit, and record where.
   8. Test backups and restores, and keep the test results.
   9. Run vulnerability scans and track findings to closure.
   10. Keep an asset inventory: which servers exist, who owns them, what they do.
Collecting evidence (make it boring and repeatable):
   sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|maxauthtries|clientalive|allowgroups'
   getent group sudo    # Ubuntu.  On RHEL family use: getent group wheel
   sudo auditctl -l
   timedatectl status
   sudo ss -tulpn
   sudo dnf updateinfo list security   or   apt list --upgradable
   sudo usg audit cis_level1_server    or   sudo oscap xccdf eval --profile cis --results r.xml --report r.html <ssg-rhelX-ds.xml>
Run these from a scheduled job that saves output into a dated folder. The same file each quarter, with a different date, is a very good audit story.

   - A list of all servers and their owners, then a random sample of servers to test.
   - Access lists for the sample, and the tickets showing when access was granted or removed.
   - Patch dates and evidence of the last kernel reboot on sampled servers.
   - Configuration scan reports and the follow-up on failures.
   - Log samples, the retention setting, and evidence of review.
   - A few recent changes: ticket, approval, test evidence, deploy record.
   - Backup jobs and at least one restore test.

"The auditor asks for the same evidence again next quarter and we cannot find it": automate collection into dated folders. Evidence you cannot find does not exist.
"We hardened everything but have no policy": both frameworks need documented policies and procedures that match what you do. Write them short and true.
"Leaver accounts were still active": the classic finding. Tie account removal to the HR offboarding ticket and check it monthly.
"Exceptions everywhere with no reasons": write each exception with the reason, the approver and a review date.
"Our sample server was different from the standard": drift. Use images and config management, and scan on a schedule.
"A control worked for six months and then silently stopped": that is why SOC 2 Type II exists. Add monitoring and alerts for the controls themselves (log shipping stopped, scanner did not run).
"ISO 27001 versus SOC 2, which one?": customers and regions decide. ISO 27001 is international and certified against a standard; SOC 2 is a US-style attestation report. Many companies do both, and share most of the evidence.

One control set, many frameworks: map your controls once (see the NIST sheet) and reuse them for ISO 27001, SOC 2, PCI DSS and HIPAA.
Keep the scope small and clear: which systems, which data, which teams.
Involve the auditor early about scope and evidence format. A ten-minute chat saves weeks.
Write down every exception, and review it on a schedule.
Automate evidence, not just controls.
An audit is a lot less scary when the answer to "show me" is a folder.

ISO 27001:2022 transition (deadline 31 October 2025):   https://www.bsigroup.com/en-IE/insights-and-media/insights/blogs/transition-to-the-iso-iec-27001-2022-standard/
ISO 27001:2022 transition guidance:                     https://www.lrqa.com/en/insights/articles/preparing-for-iso-270012022-transition-by-october-2025/
SOC 2 Trust Services Criteria overview:                 https://cloudsecurityalliance.org/blog/2023/10/05/the-5-soc-2-trust-services-criteria-explained
SOC 2 Trust Services Criteria (SANS):                   https://www.sans.org/blog/soc-2-trust-services-categories
Official standards: ISO/IEC 27001:2022 and 27002:2022 (iso.org) and the AICPA Trust Services Criteria (aicpa-cima.com)