Turn laws, contracts, frameworks, internal policies, risk decisions, and technical baselines into a clear set of evaluation rules without testing the same control repeatedly under different labels.
Criteria are the rules used to decide whether the observed condition is acceptable.
Begin with the audit objective, the systems and data in scope, the intended conclusion, and the obligations that truly apply. A checklist can support fieldwork, but it is not a substitute for selecting criteria that are authoritative, relevant, measurable, and available to the people responsible for the control.
A practical hierarchy prevents a voluntary framework from being treated as law, or an internal standard from being ignored when it is more restrictive than a general external requirement.
Identify legal requirements, regulatory rules, customer or supplier security clauses, insurance conditions, government contract terms, data-processing obligations, and other commitments that establish mandatory outcomes. Confirm applicability with qualified legal or compliance stakeholders when interpretation is uncertain.
Select the specific version and applicable portions of NIST, CIS, ISO/IEC, SOC 2 Trust Services Criteria, HIPAA, PCI DSS, CMMC, or another recognized source. Record whether the audit is a readiness review, internal assurance engagement, or preparation for an assessment performed by an authorized external party.
Include approved password standards, access-review requirements, logging baselines, network-zone rules, encryption standards, retention schedules, secure configuration baselines, incident procedures, and other management commitments. Verify that employees and control owners could reasonably know the requirement.
Use vendor and authoritative hardening guidance to make broad requirements testable. Record the product edition, operating mode, license limitations, supported configuration, and compensating safeguards so the expected condition matches the real environment.
A valid exception can change the expected condition only when the decision is authorized, time-bound, scoped, supported by risk analysis, and paired with monitoring or compensating safeguards. An undocumented operational habit is not an accepted criterion.
These sources overlap, but they are not interchangeable. The audit charter should state which source owns the conclusion and which sources provide supplemental implementation or mapping detail.
Useful for risk-based cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. It supports program-level profiles and gap discussions but often needs more detailed criteria for technical testing.
Review the NIST CSF 2.0 publicationProvides detailed security and privacy control families that can support control selection, technical procedures, and evidence planning. Tailoring, baseline selection, parameters, and system scope must be documented.
Review NIST SP 800-53 Rev. 5Offers prioritized safeguards and implementation groups that are practical for defensive improvement. Use the current safeguard language, record the selected implementation group, and avoid assuming a safeguard alone satisfies every legal or contractual requirement.
Review the current CIS ControlsCenters on an information security management system, risk treatment, continual improvement, and applicable controls. The statement of applicability, documented scope, risk process, and management-system requirements are essential to interpretation.
Review the ISO/IEC 27001 overviewSupports examination of controls relevant to security and selected availability, processing integrity, confidentiality, or privacy criteria. Define the service-organization system, commitments, system boundaries, and period before reusing SOC 2 language.
Review the AICPA SOC resourcesApplies to regulated entities and electronic protected health information. Map administrative, physical, and technical safeguards to actual ePHI systems, workflows, business associates, risks, and documentation obligations.
Review HHS Security Rule guidanceApplies to the defined cardholder data environment and connected-to or security-impacting systems. Scope validation, customized or compensating control documentation, testing procedures, and the correct validation method remain distinct.
Review the PCI SSC v4.0.1 updateConnects Department of Defense contract requirements to the protection of federal contract information or controlled unclassified information. Confirm the required level, assessment path, environment boundary, and authoritative program rules.
Review the official CMMC program overviewImportant: A readiness review or internal audit can help identify gaps, but it does not replace certification, attestation, validation, or assessment performed by an authorized external body when one is required.
The map should reduce duplicated evidence requests and procedures, not collapse meaningful differences between frameworks, systems, periods, populations, or required conclusions.
Capture the exact source citation, version, original wording, scope, parameters, and effective date. Write a plain-language interpretation without discarding the authoritative text.
State the condition the control should achieve, such as preventing unauthorized privileged access, detecting unapproved changes, or recovering a critical service within an approved time.
List the policies, people, workflows, configurations, applications, service providers, monitoring processes, and recovery capabilities that collectively support the objective.
Identify system-generated records, configurations, approvals, tickets, logs, reports, interviews, and observations that demonstrate design, implementation, and operation during the stated period.
Select inspection, observation, inquiry, reperformance, configuration comparison, sampling, or another approved method. Define the population, period, expected result, exception rule, and safety limit.
Associate the same test package with other criteria only when the objective, implementation, scope, period, and evidence genuinely overlap. Record differences that require supplemental work.
Evaluate each applicable criterion using its own wording, scope, evidence requirement, exception treatment, and reporting obligation. A passed common test does not automatically satisfy every mapped requirement.
Framework labels change. A defensible map stays understandable because it connects each label to the security outcome, implementation, evidence, and procedure that the audit actually evaluated.
Security responsibilities, policies, risk decisions, exceptions, oversight, and reporting are assigned and performed by authorized people.
Systems, identities, software, cloud services, vendors, information types, and dependencies are inventoried accurately enough to define coverage.
Access is authorized, least-privileged, reviewed, monitored, and removed when no longer needed, with stronger safeguards for privileged and sensitive activity.
Technology is configured to approved baselines, vulnerabilities and unsupported components are addressed, and changes are authorized, tested, recorded, and reversible.
Relevant events are collected, analyzed, escalated, investigated, contained, and used to improve defenses and operating procedures.
Critical services, data, configurations, and dependencies can be restored within approved objectives using protected, tested, and monitored recovery capabilities.
Each row should be narrow enough to test, but complete enough that another qualified auditor can understand what was required, how it was implemented, which evidence was examined, and why the conclusion follows.
| Control objective | Criteria and source | Scoped implementation | Expected evidence | Audit procedure | Difference or exception rule | Owner and review |
|---|---|---|---|---|---|---|
| Privileged access is limited and reviewed. | Applicable external access-control criteria; internal privileged-access standard; contractual administrator restrictions. | Directory roles, cloud roles, local administrator controls, service accounts, break-glass accounts, PAM workflow, and quarterly review. | Authoritative account and role exports, approvals, review records, HR status, PAM logs, exceptions, and configuration evidence. | Reconcile privileged identities; sample assignments and use; inspect review completeness; test termination and emergency access cases. | Separate standing from eligible access; record unmanaged local accounts, unsupported systems, and time-bound exceptions. | Identity owner; system owners; audit preparer; independent reviewer. |
| Security-relevant changes are authorized and traceable. | Change-control criteria from applicable framework; internal change standard; customer availability commitments. | Service desk, infrastructure as code, cloud changes, firewall changes, emergency process, testing, approvals, and rollback plans. | Change population, approvals, timestamps, code or configuration diffs, test results, implementation logs, incidents, and rollback evidence. | Validate the population; sample normal and emergency changes; compare approvals and implementation; inspect failed or unauthorized changes. | Do not combine application and infrastructure populations when workflows differ; expand testing when exceptions indicate a systemic gap. | Change manager; technical owner; service owner; audit reviewer. |
| Critical events are collected and investigated. | Logging, monitoring, incident, and retention criteria; internal detection standard; regulated-data obligations. | Endpoint, identity, network, cloud, application, and security-platform sources feeding SIEM, MDR, or operational monitoring. | Source inventory, ingestion health, parsing, retention configuration, alert rules, tickets, escalation records, and incident samples. | Reconcile expected sources to active ingestion; inspect gaps and exclusions; sample alerts through closure; validate timestamps and retention. | A healthy agent is not proof of usable central logging; document licensing, parsing, time, retention, and ownership limitations separately. | SOC or MDR owner; platform owners; incident lead; audit reviewer. |
| Critical information and services can be restored. | Recovery and availability criteria; business impact decisions; contractual RTO/RPO; internal backup and recovery standard. | Protected backup repositories, immutability, access control, monitoring, restore testing, application recovery, failover, and failback. | Coverage reports, job history, failure tickets, repository settings, restore records, recovery exercises, capacity, and dependency evidence. | Reconcile critical assets to protection; inspect failures; sample restores; compare measured results with approved objectives and scope. | Successful backup jobs do not prove recoverability; record missing dependencies, untested applications, partial restores, and stale objectives. | Recovery owner; application owners; infrastructure team; audit reviewer. |
| Security exceptions are controlled. | Risk-management and exception requirements; internal risk-acceptance procedure; relevant contractual notification conditions. | Exception register, approval workflow, risk analysis, compensating controls, expiration, monitoring, renewal, and closure. | Complete exception population, approvals, risk records, owner acknowledgment, monitoring output, expiration alerts, and closure evidence. | Validate completeness against technical deviations and overdue findings; sample authorization and monitoring; inspect expired exceptions. | Operational necessity alone is not approval; treat missing owner, scope, expiration, or monitoring as a control-design or implementation issue. | Risk owner; security governance; technical owner; audit reviewer. |
| Third-party access and services are governed. | Supplier, privacy, contractual, and service-provider criteria; internal vendor-risk and access standards. | Due diligence, contract clauses, access provisioning, data flows, assurance reports, monitoring, renewal review, and termination. | Vendor inventory, criticality, contracts, reviews, access records, SOC reports, issues, monitoring, and offboarding evidence. | Reconcile procurement, accounts, applications, and data flows; sample critical providers; inspect report scope and complementary controls. | A third-party report is relevant only when its service, system, period, criteria, exceptions, and complementary user controls match the environment. | Business owner; procurement; legal or privacy; IT owner; audit reviewer. |
The same control objective may operate differently across subsidiaries, cloud tenants, networks, applications, facilities, or service providers. Keep separate rows or supplemental procedures when implementation or ownership changes.
A current configuration screenshot cannot demonstrate operation over a twelve-month period. Reuse evidence only when its date range, frequency, population, and freshness meet each mapped criterion.
One framework may require a broad outcome while another specifies a technology, frequency, approval, retention, or testing detail. The common procedure must be supplemented where precision differs.
Management assertions or a policy may support design, but they do not replace system-generated records, independent corroboration, configuration evidence, or reperformance needed for operating-effectiveness conclusions.
Frameworks can treat compensating controls, customized approaches, deficiencies, significant exceptions, or plans of action differently. Preserve those rules in the criterion-specific conclusion.
An internal improvement review, compliance readiness engagement, customer assurance response, and formal certification preparation can use related work, yet their users, materiality, wording, and required independence differ.
A compensating control must address the intent and rigor of the original requirement within the real threat, architecture, and operating context. Labeling a different practice “compensating” does not make it adequate.
Explain why the original requirement cannot be met, which systems and data are affected, how long the constraint will exist, and who approved the decision.
Define the risk the original control addresses and demonstrate how the alternate design provides comparable or stronger prevention, detection, response, or recovery.
Inspect every component, dependency, monitoring activity, escalation path, owner, and evidence source required for the alternate safeguard to operate.
Use period evidence, exception samples, alert or ticket records, reperformance, and independent corroboration rather than relying only on a policy or architectural claim.
Record remaining exposure, affected obligations, renewal or expiration, remediation milestones, and conditions that would invalidate the compensating control.
Some programs prescribe how compensating controls, customized approaches, plans of action, or exceptions must be documented and approved. Apply the exact governing rule.
A small criteria review at the start prevents weeks of collecting evidence that cannot support the intended conclusion.
Record the original and revised criterion, reason, affected objectives, systems, evidence requests, completed procedures, schedule, finding evaluation, approver, and effective date. Reassess work already performed when the rule changes.
Document why requirements were combined, kept separate, supplemented, or excluded. A reviewer should be able to challenge the decision without reconstructing it from scattered spreadsheets or meeting notes.
Capture the control deviation, affected criteria, risk, compensating safeguards, owner, approval, expiration, monitoring, remediation plan, evidence, and status. Reconcile the register to observed technical exceptions and open findings.
Protect the approved map from uncontrolled edits. Retain the source version, preparer, reviewer, approvals, review notes, release date, and relationship to the work program and final report.
Use the internal security audit planning guide to define scope, authority, rules of engagement, roles, production safeguards, and change control before criteria are approved.
The internal security audit process guide connects criteria to the work program, evidence, sampling, testing, exceptions, findings, reporting, and retesting.
OC Security Audit can provide independent audit and validation guidance through the Internal Security Audit Services resource center. When approved controls require operational implementation, IT Perfection can support co-managed IT implementation without replacing the auditor's conclusion.
Ali Hassani brings more than 25 years of experience across cybersecurity, compliance, Microsoft infrastructure, cloud, firewalls, vulnerability management, backup, networking, and IT operations. That depth helps distinguish a useful control objective from a superficial framework crosswalk and connects governance requirements to evidence that can actually be tested.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience. Review Ali Hassani's professional background.
One implemented control and evidence package may support several related requirements. The map must document the relationship, and each requirement still needs a separate conclusion based on its own scope, wording, period, evidence, and exception rules.
No. Use the binding and relevant criteria for the objective. Additional frameworks may provide useful implementation detail or cross-reference support, but unnecessary frameworks can inflate scope and obscure the conclusion.
If the policy is approved, applicable, current, and available to responsible personnel, it can be valid audit criteria. Document its authority and resolve any conflict before testing rather than weakening the criterion after an exception appears.
No. A crosswalk shows a proposed relationship between requirements. Compliance or assurance depends on applicability, implementation, evidence, testing, exceptions, scope, period, and the authorized assessment or validation process.
Review it before each engagement and when laws, contracts, framework versions, systems, data flows, service providers, risks, policies, or accepted exceptions change. Record the review and its effect on open work.
The audit lead should propose the criteria, but the authorized sponsor and relevant legal, compliance, privacy, risk, technical, and control owners should confirm applicability, interpretation, scope, conflicts, and exceptions before fieldwork.
OC Security Audit can help organizations in Orange County, Irvine, Los Angeles County, and Southern California select applicable criteria, map control objectives, design evidence requests, test controls, document findings, and validate remediation without presenting a readiness checklist as a substitute for independent assurance.
This tool and guide are for initial guidance only and do not replace a professional cybersecurity audit, compliance assessment, penetration test, certification assessment, attestation, or legal/compliance review.