[{"criteria":"Security (common criteria) \u2014 logical access; authentication of users before granting access","domain":"Access control","howto":[["Identity provider (Okta, Entra ID, Google Workspace, JumpCloud)","This is the strongest evidence and where to start. Screenshot the authentication or sign-on policy showing the factor requirement and who it applies to, then export the user list with MFA enrolment status. In Entra ID that is the Conditional Access policy plus an authentication-methods report; in Okta, the global session policy and app sign-on policy plus a user report; in Google Workspace, the 2-Step Verification enforcement setting plus the user list with the 2SV column. Show the policy is ON and in 'enforced' state, not 'report only' \u2014 a Conditional Access policy in report-only mode enforces nothing, and auditors look for this specifically."],["Application-level settings (where the app has its own)","For each in-scope application, screenshot its security/authentication settings page: minimum length, complexity, lockout threshold, session timeout, and whether SSO is mandatory. If the app allows both SSO and local passwords, show that local login is disabled \u2014 otherwise the identity provider's MFA is bypassable and the whole control fails."],["Cloud consoles (AWS, Azure, GCP)","AWS: the IAM credential report is the single best artefact \u2014 `aws iam generate-credential-report` then `aws iam get-credential-report --query Content --output text | base64 -d > credential-report.csv`. It lists every user, whether MFA is active, password age and key age, in one file. Also capture the account password policy: `aws iam get-account-password-policy`. Azure: the Conditional Access policy plus `Get-MgReportAuthenticationMethod...` or the authentication methods activity report. GCP: the org policy and the Cloud Identity 2SV enforcement setting."],["Oracle Cloud Infrastructure (OCI)","First establish which IAM you are on, because the evidence differs: newer tenancies use identity domains, older ones the legacy IAM. With identity domains, capture the password policy and the MFA settings under the domain's security settings, plus the sign-on policies \u2014 these are OCI's equivalent of Conditional Access and carry the same question of who they actually apply to, so show the group scope rather than just that a policy exists. Export the user list from the domain with the MFA enrolment attribute. On legacy IAM, `oci iam user list --all` returns `is-mfa-activated` per user, which is the single cleanest artefact \u2014 the equivalent of the AWS credential report. Two OCI-specific traps worth pre-empting, because an auditor who knows the platform will ask: federation, where the tenancy federates to an external identity provider and the real MFA control lives there \u2014 produce the IdP evidence too, and show that local IAM users cannot bypass it; and API signing keys and auth tokens, which authenticate without any interactive factor at all, so list who holds them and how they are governed. Also capture the membership of the tenancy Administrators group, which is the first thing looked at."],["Linux servers with direct access","Show that password authentication is off, so the authentication control is the key rather than the password policy: `sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|pubkeyauthentication'` captures the effective running configuration rather than what the file says, which is the distinction auditors care about. Add `grep -E '^(PASS_MAX_DAYS|PASS_MIN_LEN)' /etc/login.defs` and the PAM password quality configuration if local accounts exist at all."],["Databases","Frequently missed and frequently the weakest point, because a database often allows local authentication that bypasses SSO entirely. Show the authentication method configuration (for PostgreSQL, `pg_hba.conf` and `SHOW password_encryption;`) and the account listing. If humans connect directly to production databases, the auditor will follow that path."],["The 'in-scope' part","Before producing anything, confirm which applications are in scope with the practitioner and produce the same evidence for every one of them. A complete set for four applications when the system description names six is an immediate follow-up request."]],"id":"auth-settings-prod-apps","intent":"The auditor is not collecting your password policy for its own sake. They are testing that access to production is protected by an authentication mechanism that is actually enforced, and that its configuration matches what your own policy claims. Two separate assertions: the setting exists, and it applies to everyone in scope. The parenthetical about MFA is the part that carries most of the weight \u2014 password rules are weak evidence on their own, and a configured MFA policy with no exceptions is strong evidence.","produce":["The authentication policy configuration for each in-scope production application and for the identity provider in front of them.","Evidence that MFA is enforced \u2014 the policy, and the population it applies to.","A user listing for each in-scope application showing MFA status per user, so the auditor can see there are no uncovered accounts.","The list of any exceptions (break-glass, service accounts) with their compensating controls.","Your written password/authentication policy, so the configuration can be compared against what you committed to."],"rejects":["A policy document with no configuration screenshot \u2014 that shows intent, not enforcement.","A screenshot of MFA on the auditor's own test account, or on yours. The request is about the population, not one user.","A Conditional Access or sign-on policy left in report-only mode.","A user list where some accounts show no MFA and the exceptions are not explained.","Evidence for the identity provider only, when applications also accept local logins that bypass it.","Undated screenshots, or screenshots dated after the observation period closed."],"related":["/security-settings","/user-management-permissions"],"request":"Password or authentication settings for in-scope production applications (include screenshots of MFA in use if applicable)"},{"criteria":"Security (common criteria) \u2014 logical access; protection against repeated unauthorised authentication attempts","domain":"Access control","howto":[["Identity provider","Where SSO is in place this is the primary artefact and often the only one that matters, because the applications never see a password. Screenshot the lockout or sign-on policy showing threshold, duration and reset window, and show which users or groups it applies to. Entra ID's smart lockout and Okta's authentication policy both expose these as explicit numbers."],["Applications with their own authentication","Per in-scope application, the security settings page showing the threshold and duration. If an application has no lockout capability at all, do not hide it \u2014 state it, and describe the compensating control, which is typically a WAF or gateway rate limit in front of it. An acknowledged limitation with a compensating control is a normal finding; a silent one is not."],["Cloud consoles","AWS: the account password policy has no lockout setting, which surprises people \u2014 `aws iam get-account-password-policy` will not answer this request. The honest answer is that console access is protected by MFA and by federation, and that is what you evidence. Azure: the Entra ID smart lockout threshold and duration. GCP and OCI: the policy in the identity domain or Cloud Identity settings."],["Linux servers","Only relevant if password authentication is possible at all, so lead with whether it is: `sshd -T | grep -i passwordauthentication`. If it returns `no`, that is your evidence, and it is better evidence than a lockout number. Where local passwords do exist, show the PAM faillock or tally configuration (`grep -r faillock /etc/pam.d/ /etc/security/faillock.conf`) with deny count and unlock time, plus `faillock --user <name>` to show it is actually recording. If you run fail2ban or similar at the network layer, include its jail configuration \u2014 it is a different control but it answers the same underlying risk and auditors accept it when described as such."],["Databases","Often the weakest point, because databases frequently allow local authentication with no lockout whatsoever and sit behind nothing. Show the account policy where the engine supports one, and where it does not, show what restricts reachability instead \u2014 network policy, private subnet, no route from outside."],["Proving it works, if asked","Some auditors ask for demonstrated behaviour rather than configuration. A short screen recording or a screenshot sequence of a test account being locked after the threshold, timestamped, settles it. Use a dedicated test account, never a real user's."]],"id":"account-lockout","intent":"A companion to the authentication-settings request, and usually sent alongside it. The auditor is testing that repeated failed logins are throttled or stopped rather than allowed to continue indefinitely, and that the configured values match what your own policy states. As always, you are measured against your own commitment, which is a good reason for the policy to describe what you actually do. One nuance worth understanding before you answer, because it changes what good evidence looks like: where you have disabled password authentication entirely, lockout thresholds are close to irrelevant \u2014 there is no password to guess. Saying that plainly, and showing the configuration that proves it, is a stronger answer than producing a lockout number for a system nobody can attempt a password against. Say it explicitly though; leaving the field blank reads as an omission.","produce":["The lockout configuration per in-scope production application and for the identity provider: threshold, lockout duration, and reset or observation window.","Your written policy, so the configuration can be compared against it.","Evidence of what happens on lockout \u2014 automatic unlock after a period, or a verified manual unlock process.","Where lockout does not apply because password authentication is disabled, the configuration demonstrating that.","Any systems deliberately excluded, with the reason and what protects them instead."],"rejects":["A policy document stating a threshold, with no configuration screenshot.","Configured values that do not match the stated policy \u2014 either is defensible, the mismatch is not.","Evidence for the identity provider only, while an application also accepts local logins with no lockout.","A blank or omitted answer for a system where password login is disabled, instead of saying so and showing the configuration.","Lockout with no unlock path, or an unlock process with no identity verification \u2014 an unlock that anyone can request by email is its own weakness.","Undated screenshots, or ones taken after the observation period ended."],"related":["/security-settings","/user-management-permissions"],"request":"Account lockout settings for in-scope production applications"},{"criteria":"Security \u2014 logical access; least privilege","domain":"Access control","howto":[["Identity provider","Export all users with their group memberships and application assignments. This is the master list the others are reconciled against."],["AWS","`aws iam list-users`, `aws iam list-roles`, and per user `aws iam list-attached-user-policies` / `list-groups-for-user`. The credential report also covers most of this in one file."],["Linux","`getent passwd` for accounts and `getent group sudo wheel` (or your elevation group) for who can escalate \u2014 the second is the one that gets tested."],["Databases","The role and grant listing; for PostgreSQL `\\du` or a query against `pg_roles`, including which roles carry SUPERUSER."],["SaaS applications","Each admin console has a user export. Include the role column \u2014 a list of names without permission levels does not answer the request."]],"id":"user-access-listing","intent":"The auditor needs the population before they can sample anything else. This listing is also what the joiner/leaver and access-review tests are checked against, so an incomplete one undermines several later tests rather than just this one.","produce":["One export per in-scope system: username, full name, role or group, status, creation date, last login.","A mapping of service and shared accounts to an owner and a purpose.","The date the export was taken, and by whom."],"rejects":["Active users only, when the request said complete \u2014 disabled accounts that were never removed are exactly what is being looked for.","No role or permission column.","Service accounts with no named owner."],"related":["/user-management-permissions"],"request":"Complete user listing for in-scope systems, including role or permission level"},{"criteria":"Security \u2014 logical access is periodically reviewed and modified as needed","domain":"Access control","howto":[["If you run reviews in a ticket or GRC system","Export the ticket with its full history: the assignment, the reviewer's comments, the sign-off, and linked remediation tickets. This is the cleanest form."],["If you run reviews in a spreadsheet","Keep the file for each cycle with reviewer name and date inside it, and keep the removal tickets it generated. Store them somewhere with reliable timestamps \u2014 a file whose only date is 'last modified' is weak."],["Closing the loop","For each access the review said to remove, produce the removal evidence: the ticket, and a later user listing that no longer contains the account. That before-and-after pair is the strongest version of this evidence."]],"id":"access-review","intent":"Testing that somebody with authority looked at who has access, decided it was still appropriate, and acted where it was not. The review happening is half of it; the other half is that the removals it identified were actually carried out. Auditors routinely find reviews completed with findings and no follow-up.","produce":["The review record for each occurrence in the period, at your stated frequency.","Who performed it, who approved it, and the date \u2014 approval by someone other than the person being reviewed.","The listing the review was performed against.","The resulting actions, and evidence each one was completed with its date."],"rejects":["One review when your policy says quarterly and the period was twelve months.","A review with findings and no evidence they were remediated.","Self-review \u2014 the system owner reviewing their own access.","A signed summary with no underlying listing attached."],"related":["/user-management-permissions"],"request":"Evidence of periodic user access reviews performed during the period"},{"criteria":"Security \u2014 access is removed when no longer required","domain":"Access control","howto":[["The leaver list","From HR, not from IT. Reconciling the HR list against your identity provider is the test, so the populations have to come from different sources."],["Identity provider","The system log entry for the deactivation, with its timestamp. Okta's system log, Entra ID's audit log, Workspace's admin audit log all export this."],["Anything outside SSO","The accounts most often missed: VPN, database logins, cloud console IAM users, source control, CI/CD, monitoring, on-call paging, shared password vault. Produce evidence per system, not just for the IdP."]],"id":"jml-termination","intent":"Comparing two dates: when the person left, and when their access ended. The control is your stated timescale, so the test is against your own commitment rather than an external standard \u2014 which makes an unrealistic policy actively harmful.","produce":["The complete list of leavers in the period, with termination dates \u2014 the auditor samples from it.","Per sampled leaver: the offboarding ticket, the deactivation record from each system, and the timestamp of each.","Evidence the account is gone now, from a current listing."],"rejects":["An HR list and an IdP list that disagree.","A revocation date later than your policy allows, with no explanation.","Evidence for SSO only, while a git or database account for the same person is still active."],"related":["/user-management-permissions"],"request":"For a sample of terminated employees, evidence that access was revoked timely"},{"criteria":"Security \u2014 changes are authorised, designed, tested and approved before implementation","domain":"Change management","howto":[["The population","The hardest part, because changes arrive through several paths. Deployment logs from the pipeline are usually the best single source. If changes can also be made outside the pipeline, that population has to be included too \u2014 and the auditor will ask how you know it is complete."],["Git and code review","The PR page shows author, reviewer, approval time and merge time in one view. `git log --merges --since=... --pretty=format:'%h %ad %an %s'` gives the population; the PR link gives the detail."],["Pipeline","The run record: what was built, which tests ran and passed, who triggered it, when it deployed, and to which environment."],["Emergency changes","Handle these explicitly rather than hoping they are not sampled. Show the retrospective approval and that it followed your documented emergency process. An emergency path is acceptable; an undocumented one is not."]],"id":"change-management-sample","intent":"Following individual changes end to end. The specific thing being tested is that approval happened *before* deployment and by someone other than the author \u2014 so timestamps matter as much as the existence of each artefact.","produce":["The complete population of production changes in the period, so the auditor can sample.","Per sampled change: the ticket, the pull request with reviewer and approval timestamp, the test or pipeline result, and the deployment record with its timestamp."],"rejects":["Approval timestamped after deployment.","The author approving their own change.","A change in production with no corresponding ticket or PR.","A population that omits hotfixes or manual changes."],"related":["/cicd-setup"],"request":"For a sample of changes, evidence of request, approval, testing and deployment"},{"criteria":"Security \u2014 segregation of duties; restricted deployment capability","domain":"Change management","howto":[["Source control","Screenshot branch protection: required reviews, dismiss stale approvals, restrict who can push, and \u2014 the one that gets checked \u2014 whether administrators can override."],["Pipeline","The environment protection rules and the list of approvers."],["Cloud","`aws iam list-entities-for-policy` for the production deployment role, or the equivalent role assignment listing, showing who can assume it."],["Standing access","If engineers hold permanent production credentials, expect scrutiny. Time-bound elevation with an approval trail is far easier to evidence than explaining why it is not needed."]],"id":"prod-access-restriction","intent":"Testing that the change-management control cannot be bypassed. If anyone can push directly to production, every other change control is advisory.","produce":["Branch protection settings on production branches.","The list of who can approve and merge, and who can trigger a production deployment.","Cloud IAM showing who holds write access to production infrastructure.","Evidence that the pipeline's own credentials are not held by individuals."],"rejects":["Branch protection with an admin override that several people hold.","A shared deployment account whose credentials are in a wiki.","A list of authorised deployers that does not match the actual permissions."],"related":["/cicd-setup","/user-management-permissions"],"request":"Evidence that access to deploy to production is restricted to authorised personnel"},{"criteria":"Security \u2014 vulnerabilities are identified, evaluated and remediated","domain":"Vulnerability management","howto":[["Scanners","Export the scan history showing dates and target counts \u2014 coverage is tested as well as findings. A scan of 40 hosts when the estate has 60 is a gap."],["Container and dependency scanning","Pipeline scan output per build, plus how the gate behaves on a finding."],["Cloud posture","Security Hub, Defender for Cloud or SCC findings with their timeline."],["Proving the timeline","The strongest artefact is a report with discovery date, severity and closure date in one row per finding \u2014 it demonstrates the SLA directly rather than requiring the auditor to cross-reference."]],"id":"vulnerability-management","intent":"Two things: that scanning happens at your stated frequency across the whole estate, and that findings are closed within your own stated SLA. As with offboarding, you are measured against your policy \u2014 a policy promising 7 days for criticals when you achieve 30 creates exceptions that a 30-day policy would not.","produce":["Scan reports across the period at the stated frequency, showing coverage.","The findings register with severity, discovery date, and closure date.","Remediation tickets for a sample.","Documented, approved risk acceptances for anything open past its SLA."],"rejects":["A single recent scan for a twelve-month period.","Scans covering part of the estate.","Open criticals past SLA with no risk acceptance.","A clean report with no evidence of what was scanned."],"related":["/security-patch-management"],"request":"Vulnerability scan results and evidence of remediation within defined timeframes"},{"criteria":"Security \u2014 system components are maintained and updated","domain":"Vulnerability management","howto":[["Linux","`grep -E 'Unattended-Upgrade|APT::Periodic' -r /etc/apt/apt.conf.d/` or `systemctl is-enabled dnf-automatic.timer`, plus `/var/log/dpkg.log` or `dnf history` as proof updates actually applied. `uptime` alongside it \u2014 a kernel patched and never booted is not applied."],["Fleet-wide","Patch manager or configuration management compliance report, which covers population and status in one artefact."],["Containers","Base image rebuild cadence and the registry scan history."]],"id":"patch-evidence","intent":"That patching is a running process rather than an occasional effort, and that it covers the whole in-scope estate including anything outside the automation.","produce":["Patch status per host across the period.","Configuration showing automatic security updates enabled, where claimed.","The reboot record for kernel updates.","Exceptions with their justification."],"rejects":["Configuration showing automation is enabled, with no evidence it ran.","Hosts absent from the report that appear in the asset list.","Long uptimes on hosts whose kernel was patched."],"related":["/security-patch-management","/scheduled-maintenance"],"request":"Evidence that systems are patched in line with policy"},{"criteria":"Availability \u2014 data is backed up and recoverable","domain":"Backup and recovery","howto":[["Job history","Export from the backup tool or cloud backup service covering the full period, not a screenshot of this week."],["Home-grown scripts","The log plus the cron or timer definition, plus how a failure raises an alert. A script that fails silently is the finding, not the evidence."],["Snapshots","The snapshot listing with timestamps and the lifecycle policy."],["Failure handling","If nothing failed, say so and show the alerting would have fired \u2014 a test alert, or a failure from outside the period."]],"id":"backup-evidence","intent":"Not that backups are configured \u2014 that they ran, that somebody would know if one did not, and that failures were acted on. A period with zero recorded failures often means nobody is watching rather than that nothing failed, and auditors read it that way.","produce":["Backup job history across the period, showing successes and failures.","The alerting configuration for failures.","For a sampled failure, the ticket and its resolution.","The retention configuration, against your stated policy."],"rejects":["A screenshot of a backup dashboard showing 'last run: success'.","No failures and no evidence that failures are detectable.","A failure with no ticket."],"related":["/backup-and-recovery","/scheduled-maintenance"],"request":"Evidence that backups are performed and monitored, including failure handling"},{"criteria":"Availability \u2014 recovery procedures are tested","domain":"Backup and recovery","howto":[["Automated tests","The job log per run, including the validation step \u2014 a row count, a checksum, a query returning an expected value. 'Restore completed' is not validation."],["Manual tests","A short written record is enough, provided it names the date, the performer, what was restored, how it was checked and how long it took. Make it a template so each test produces the same record."],["DR exercises","The exercise plan, the outcome, and the actions arising \u2014 which also serves ISO 22301 if you hold it."]],"id":"restore-test","intent":"The control is recoverability, and the only evidence of recoverability is a restore. This is the request organisations most often cannot satisfy, because backups are monitored and restores are not tested.","produce":["The restore test record: date, what was restored, to where, by whom.","How the restored data was validated \u2014 this is the part usually missing.","The elapsed time, compared against your stated recovery objective.","Any issues found and what was done about them."],"rejects":["No restore test in the period.","A restore with no validation of the restored data.","A test of a non-production system presented as covering production."],"related":["/backup-and-recovery","/disaster-recovery-planning"],"request":"Evidence of backup restoration testing performed during the period"},{"criteria":"Security \u2014 the system is monitored and anomalies are evaluated","domain":"Monitoring and logging","howto":[["Alert configuration","Export the rule definitions rather than screenshotting a dashboard \u2014 rules are the control, dashboards are a view."],["Routing","The on-call schedule and escalation policy from the paging tool, covering the period."],["Response","For sampled alerts, the acknowledgement time and the resulting ticket or note. This closes the loop that the auditor is looking for."],["Log integrity","That logs ship off the host and that the destination is append-only or access-controlled."]],"id":"monitoring-alerting","intent":"That monitoring exists, that alerts reach a human, and that the human did something. The third is where evidence is usually thin \u2014 a dashboard is not a control, and an alert nobody acted on is worse than no alert.","produce":["The alert rules or detection configuration in scope.","The routing: who is notified, by what channel, and the escalation if unanswered.","A sample of alerts from the period with the response recorded.","Evidence that log collection itself is monitored."],"rejects":["Dashboard screenshots with no alert rules.","Alerts with no evidence anyone responded.","Alerting configured to an unmonitored mailbox."],"related":["/log-aggregation","/resource-monitoring"],"request":"Evidence of security monitoring and alerting, including alert response"},{"criteria":"Security \u2014 incidents are identified, responded to and resolved","domain":"Incident management","howto":[["The register","Export from the ticketing or incident tool with timestamps intact."],["Per incident","The timeline is the evidence: detected at, acknowledged at, mitigated at, resolved at, with who did what."],["Follow-up","The post-incident review and the resulting actions with owners \u2014 see /post-incident-follow-up. An incident closed with no action is a reasonable outcome only if the review says why."],["If there were none","Say so explicitly, and show the process is live: a tabletop exercise, or operational incidents handled through the same process."]],"id":"incident-records","intent":"That the incident process is used, not that no incidents occurred. Declaring zero incidents over twelve months invites more scrutiny than declaring several handled well.","produce":["The incident register for the period, with severity and dates.","Per sampled incident: detection, triage, actions taken, resolution, and follow-up.","Evidence of customer or regulator notification where your policy required it.","The incident response procedure itself."],"rejects":["Zero incidents with no explanation of how you would know.","Incidents with no timeline.","A procedure document with no incidents run through it."],"related":["/incident-handling","/post-incident-follow-up"],"request":"Listing of security incidents during the period and, for a sample, evidence of handling"},{"criteria":"Security \u2014 vendors and business partners are assessed and monitored","domain":"Vendor management","howto":[["The inventory","Reconcile the list against what is actually paid for \u2014 finance's records find vendors that IT's list does not."],["Review record","A short note per vendor: who read the report, when, what the exceptions were, and whether the complementary user entity controls apply to you. A stored PDF with no note is a filed document, not a review."],["Ongoing","Evidence that reports are refreshed as they expire, and that a vendor with no current report was escalated."]],"id":"vendor-management","intent":"That you know who processes your data, that somebody assessed the risk, and that the assessment is refreshed. Obtaining a vendor's SOC 2 report is not the control \u2014 reading it is, including its exceptions and the complementary controls it expects of you.","produce":["The vendor inventory with what each one does and what data they touch.","Risk classification per vendor.","Assurance evidence for the significant ones, with a record that it was reviewed.","Contracts with the relevant security and data protection terms."],"rejects":["A vendor list with no risk assessment.","Stored SOC 2 reports with no evidence anyone read them.","An expired report accepted without comment."],"related":["/dependency-mapping"],"request":"Listing of third-party vendors and evidence of due diligence performed"},{"criteria":"Security (common criteria) \u2014 baseline configurations are defined and maintained for system components","domain":"Infrastructure","howto":[["Start from the inventory, not from the documents","Produce the list of in-scope system types first and get agreement on it. Writing standards before the scope is settled is how you end up with five polished documents and a sixth type nobody covered. The /infrastructure-audit output is usually the right source, and the same reconciled asset register serves both purposes."],["If the hardening lives in code and not in a document","This is the normal situation for an engineering team, and it is a good position rather than a gap. Your configuration management role, image build definition or Terraform module is the de facto standard \u2014 so generate the document from it: what the role enforces, why, and which deviations are parameterised. Do not write an aspirational document separately from the code. An auditor may sample a running host and compare it against the standard, and a document that disagrees with reality is worse evidence than no document, because it turns a coverage gap into a control failure."],["Derive from a recognised source and say which","CIS Benchmarks, vendor hardening guides, or DISA STIGs. Name the source and version in the document. Two things auditors look for: that you tailored it rather than attaching the PDF unchanged, and that the tailoring decisions were made deliberately \u2014 a recorded 'not applicable, we do not run this service' is a perfectly good answer."],["Routers and switches","Management plane access and authentication, disabled unused services and ports, SNMP community and version, logging destination, NTP, firmware baseline, and config backup. Evidence the running configuration matches: a diff of the live config against the intended one is strong, and easy to automate."],["Firewalls","The default-deny posture, rule review cadence and last review date, admin access and MFA, logging, and firmware. See /network-and-firewall-configuration \u2014 the rule set itself belongs to a different request, this one is about the standard the rule set is built to."],["Servers, by role","Web, application, database and any others each need their own standard, because what is hardened differs: a web server standard covers TLS configuration, headers and disabled modules; a database standard covers authentication method, network binding, encryption and privileged roles. A single 'server hardening' document covering all roles is the most common way this request fails. The shared base \u2014 accounts, logging, time, patching, minimal install \u2014 can sit in one common standard with role-specific ones layered on it, which is both less work and easier to defend. See /os-installation-and-hardening."],["POS and payment terminals, if you have them","Usually vendor-supplied and vendor-maintained, which does not remove them from the coverage table. Document the vendor's hardening guidance you follow, your deployment configuration, how updates reach them, and the split of responsibilities with the vendor. If you have no POS estate, put a line in the table saying so."],["Cloud, virtual and container images","Frequently missed because they do not feel like 'system types'. Base images, machine images, Kubernetes node configuration and the cloud account baseline each need a standard. For images, the build definition plus the scan gate is the document."],["Making them controlled documents","Whatever you use \u2014 a document system, or Markdown in a repository. A repo is often the better answer: the commit history is the version control and the review evidence, pull request approvals are the approval record, and it sits next to the code that implements it. Either way each document needs an owner, a version, an effective date and a recorded review inside the period."]],"id":"config-standards-docs","intent":"This request is about the documents, not about any individual machine. The auditor is testing two things. First coverage: that a configuration standard exists for every system type in scope, which they will check by laying your list of standards against your asset inventory and system description \u2014 a type that appears in the inventory with no corresponding standard is the finding, and the enumeration in the request (router, firewall, web, database, application, POS) is a prompt to make you go looking rather than an exhaustive list. Second, that each standard is a controlled document: owned, approved, versioned, dated and reviewed, rather than a wiki page somebody wrote once. Note the wording. \"System configuration standards\" and the mention of POS servers is PCI DSS vocabulary rather than SOC 2 vocabulary, so a request phrased this way is often a checklist being reused across frameworks, or a combined assessment. It is worth asking which framework the request belongs to before you answer it, because PCI expectations around configuration standards are more prescriptive than SOC 2's \u2014 and if you have no POS estate at all, say so explicitly rather than leaving a silent gap in the coverage table.","produce":["The list of in-scope system types, taken from the asset inventory and the system description \u2014 this is what coverage is measured against, so it comes first.","One configuration or hardening standard per type, as a document you can hand over.","A coverage table mapping each system type, and each asset, to the standard that governs it. This single artefact answers most of the request.","Approval evidence per standard: author, approver, version, effective date.","Evidence each standard was reviewed within your stated cycle during the period.","The recognised source each one derives from, and where you departed from it.","Documented, approved deviations \u2014 the exceptions that exist in reality."],"rejects":["One 'server hardening' document when the inventory distinguishes web, database and application servers.","Standards covering servers but not network devices, or the reverse.","A CIS Benchmark PDF attached unchanged, with no adoption or tailoring decision.","Documents with no version, no approver or no date.","No review recorded during the period when the policy says annual.","A standard that does not match the running configuration of a sampled host.","Deviations that exist on systems but appear nowhere in the documents.","A system type in the asset inventory that no standard covers, and no statement that it was consciously excluded."],"related":["/system-configuration-standards","/os-installation-and-hardening","/network-and-firewall-configuration","/infrastructure-audit","/infrastructure-as-code"],"request":"System configuration standard documents or \"system hardening procedure documentation\" for all in-scope system types (include router, firewall, servers \u2014 web, database, application, POS servers, etc.)"},{"criteria":"Security \u2014 infrastructure is configured to prevent unauthorised access","domain":"Infrastructure","howto":[["Configuration management","A check-mode or dry-run report across the fleet is the ideal artefact: it shows both the standard and the conformance in one output."],["Cloud","Config rules, policy compliance dashboards, or the equivalent posture report, exported with dates."],["Network","Security group and firewall rule exports, plus evidence they are reviewed \u2014 see /network-and-firewall-configuration."],["Encryption","That storage encryption and TLS are enforced: the setting, and a listing showing no unencrypted resources."]],"id":"infrastructure-config","intent":"That systems are built to a defined standard rather than individually, and that drift from it is detected. Configuration management makes this straightforward; hand-built servers make it painful.","produce":["The baseline itself \u2014 the configuration code or hardening standard.","Evidence it is applied across the in-scope estate.","Drift or compliance reporting across the period.","Firewall and network rules for in-scope environments."],"rejects":["A hardening document with no evidence of application.","Compliance reporting covering some hosts.","Firewall rules with no review record."],"related":["/os-installation-and-hardening","/network-and-firewall-configuration"],"request":"Evidence of secure configuration baselines for in-scope infrastructure"},{"criteria":"Security \u2014 personnel are made aware of their responsibilities","domain":"People","howto":[["Platform export","Completion report per person per course, with dates."],["Reconciliation","Against the HR list including leavers and joiners \u2014 the reconciliation is the evidence, not the raw report."],["Joiners","That training happened within the window your policy states after start date."]],"id":"security-training","intent":"Simple to satisfy and frequently failed on completeness. The test is that everyone in scope completed it, including joiners during the period and contractors if your policy covers them.","produce":["The completion report with names and dates.","The employee population for the period, to reconcile against.","The training content or its outline.","Follow-up evidence for non-completers."],"rejects":["A completion percentage with no names.","Gaps with no follow-up.","Joiners late in the period with no training and no explanation."],"related":[],"request":"Evidence that personnel completed security awareness training during the period"}]