1 Identifying Compliance Requirements

Start with scope and applicability

Compliance work starts by determining which requirements apply to an organization, its activities, and the people or systems involved. A requirement is not applicable merely because it appears on a checklist or is common in an industry. Verify its source, scope, conditions, and current status.

Define the assessment boundary

Define what the assessment covers before searching. The scope may include the legal entity or entities, locations and jurisdictions, business activities, products and services, employees and contractors, customers and suppliers, information and systems, and the period under review.

Consider how the organization’s conduct or relationships connect it to a requirement. Relevant connections may include where work occurs, whose data is handled, whether a regulated activity is performed, or whether a contract applies.

A practical boundary statement is: “This review covers the U.S. customer-support operations of Entity A, including the staff and systems processing customer records, and the customer agreements in force during the review period.” A clear boundary helps identify what is included, excluded, and still uncertain. Expand or qualify it when evidence shows that an affiliate, vendor, location, or activity falls within a requirement’s reach.

Distinguish requirement categories

Requirements come from different sources, and each source needs to be checked on its own terms.

• Laws are enacted by legislatures. Their applicability may depend on location, industry, organizational status, activities, or the people affected. In the United States, the U.S. Code is useful for general and permanent federal laws, but it does not include every kind of law; state laws and agency regulations are found elsewhere.

• Regulations are rules issued by government agencies under legal authority. Identify the regulator, exact provisions, effective dates, amendments, and applicability conditions. For U.S. federal regulations, the Code of Federal Regulations (CFR) and Federal Register are key sources. The eCFR is updated frequently but is an unofficial editorial compilation; verify important provisions against the official CFR and Federal Register for legal research.

• Standards provide technical or management requirements. A standard may be voluntary by itself, but can become obligatory when a law or regulation incorporates it, a contract requires it, or the organization adopts it as policy. Confirm the exact edition and referenced clauses rather than assuming every standard is legally mandatory.

• Contracts create obligations for their parties. Review signed agreements and amendments, including customer and supplier terms, licenses, service-level commitments, government awards, and applicable flow-down clauses. Record who must do what, for whom, by when, and what evidence or notice is required.

• Internal policies and procedures set the organization’s own rules and controls. They may implement external requirements or create additional internal commitments. Identify the approved, current version, its owner, audience, scope, and exceptions process. A policy does not replace a law or contract; escalate conflicts or gaps for resolution.

Verify requirements and interpret them

Use a repeatable process to identify and verify candidate requirements.

1. Map activities and relationships. Gather information from legal-entity records, operational teams, product and service descriptions, location lists, data flows, licenses, permits, and executed contracts.

2. Search by source and trigger. Check relevant national, regional, state, provincial, and local law; regulators’ official publications; sector-specific rules; contracts and incorporated documents; applicable standards; and internal governance documents. Search tools can locate candidates, but verify them against the issuing authority, official text, signed agreement, or controlled internal repository.

3. Test applicability. For each candidate, ask whether it covers the entity, activity, location, person, data, or transaction. Identify relevant thresholds, exceptions, and conditions; when the requirement takes effect; and whether it has been amended, renewed, or superseded. Record unanswered questions rather than treating them as settled.

4. Translate text into obligations. Capture the required action or prohibition, responsible party, deadline or frequency, triggering event, required records or notifications, and any exceptions. Preserve the precise citation or contract clause so reviewers can trace the interpretation to its source.

5. Validate interpretation. Have the appropriate legal, compliance, procurement, security, privacy, or operational owner review requirements in their area. Escalate ambiguous, conflicting, or high-impact interpretations to qualified counsel or the relevant authority. A compliance inventory supports analysis but is not, by itself, a legal determination.

Use reliable sources

Prefer an authoritative source closest to the authority that created the requirement. Examples include enacted legal texts and official government publications; a regulator’s rules, orders, and guidance; fully executed contracts and amendments; the standards publisher’s controlled edition; and approved internal policy repositories.

Guidance and summaries can help locate or understand a requirement, but check whether they are binding and confirm important conclusions against the underlying authority. For U.S. federal statutes, the Office of the Law Revision Counsel explains the United States Code and its coverage. For federal rules, use the CFR and Federal Register; the eCFR can serve as a current research aid, with verification against official editions where needed.

Document obligations in a register

Maintain a controlled requirements register so that obligations can be traced to their sources and acted on. Useful fields include:

• Requirement and source: title, issuing body or counterparty, exact citation or clause, and source link or controlled copy.

• Applicability rationale: the entity, activity, location, data, or relationship that brings the organization into scope.

• Obligation: the clear action, prohibition, threshold, or outcome required.

• Timing and evidence: deadline, frequency, trigger, required record, report, or notification.

• Owner and affected parties: accountable function and relevant employees, systems, vendors, or business units.

• Status and version: effective date, review date, amendment history, and next review trigger.

• Interpretation and open issues: assumptions, exceptions, conflicts, approvals, and unresolved questions.

For example, if an executed customer agreement requires a supplier to notify the customer within a specified period after a security incident, record the exact clause, incident trigger, deadline, responsible response team, and evidence that notification occurred. Do not generalize that obligation to other customers unless their agreements impose the same terms.

Keep requirements current

Review the register when laws or rules change, contracts are signed or renewed, products or locations change, or the organization enters a new market. Compliance policies should be integrated into operations and reviewed and revised as appropriate. A maintained, traceable inventory helps support that work.