Episode 105 — Identify Applicable Security and Privacy Laws, Regulations, and Standards
In this episode, we build on the jurisdiction and data flow foundation by learning how to identify which security and privacy laws, regulations, and standards actually apply to an organization. This sounds like a huge task, and it can feel overwhelming to beginners because there are many names, many acronyms, and many opinions about what matters most. The good news is that you do not identify what applies by guessing or by collecting every possible rule in the world. You identify what applies by understanding the organization’s context, then mapping that context to obligations and expectations that come from governments, regulators, contracts, and industry practice. Laws are legal requirements created by governments, regulations are detailed rules enforced by regulatory bodies, and standards are structured sets of controls or practices that organizations may adopt voluntarily or may be required to follow through contracts or industry expectations. Even when standards are not legally mandated, they can become practically mandatory because customers, auditors, and partners demand them. The goal is to build a disciplined method for deciding what is relevant and what is not, so the security program is both compliant and focused.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
A helpful place to start is clarifying the difference between mandatory and voluntary, because many beginners assume everything is mandatory if it sounds official. Laws and many regulations are mandatory, meaning failing to comply can lead to penalties, legal action, or loss of permission to operate. Standards can be voluntary in theory, but in practice they often become required through contracts, procurement requirements, or certification expectations. For example, a customer might require an organization to follow a particular control framework or to demonstrate specific practices in order to do business. Another partner might require evidence of security controls before sharing sensitive information. The key beginner insight is that obligations can come from multiple sources, and not all of those sources are government. An organization can be compliant with the law and still be non-compliant with contractual obligations that are essential for the business. Therefore, identifying applicable requirements is about understanding both legal mandates and business-driven expectations.
The next step is understanding what triggers a law, regulation, or standard to apply, because applicability is rarely random. Triggers often include industry, such as healthcare, finance, education, defense, or critical infrastructure, where regulators impose specific security and privacy expectations. Triggers can also include data types, such as personal data, payment data, health information, or sensitive government information, where obligations are stronger due to potential harm. Geography triggers apply as well, because jurisdictions matter, and the location of the organization, customers, or data subjects can create obligations. Business model triggers also exist, such as whether the organization provides services to others, processes data on behalf of customers, or operates as a supplier in a regulated supply chain. For beginners, it helps to treat triggers as a set of filters, like a series of questions that narrow the field. Instead of asking what laws exist, you ask what our organization does that would make certain laws relevant. That approach keeps the task manageable and reduces the risk of missing truly important obligations.
Another important concept is that security and privacy requirements can apply to different parts of an organization differently. A large organization may have business units with different customer types, different data, and different regulatory exposure. Even in smaller organizations, different systems can have different obligations based on what data they handle. This is why the identification process should include an inventory mindset, where you understand which services exist, what they do, and what information they touch. Without that, compliance efforts become either too broad or too narrow. Too broad means treating everything as equally regulated, which wastes resources and creates frustration. Too narrow means ignoring areas where obligations are real, which creates serious risk. For beginners, the takeaway is that compliance is not a single label the organization wears; it is a set of obligations that attach to specific activities and data. Accurate scoping makes compliance more achievable and more credible.
Once triggers and scope are understood, you can classify requirements into three buckets: laws, regulations, and standards, each with a different type of authority. Laws come from legislative bodies and are enforced through legal systems, often with penalties and rights for individuals. Regulations come from regulatory bodies and often include specific security and privacy expectations for industries or data categories. Standards include control frameworks, best-practice catalogs, and certification requirements that define how an organization should protect information. Standards can also include widely accepted technical and management practices that auditors and customers treat as reasonable expectations. For beginners, it is important to understand that standards often fill the gap between broad legal requirements and day-to-day security controls. A law might require reasonable safeguards, but it may not specify exactly how to implement them, while a standard provides detailed guidance on what controls and processes are considered reasonable. This relationship is why standards often become the backbone of security programs even when the law is the original driver.
Identifying applicable requirements also requires recognizing overlaps and conflicts, because an organization can be subject to multiple requirements that address similar risks in different language. Privacy laws may require protecting personal data, while security regulations may require protecting systems, and a standard may describe how to manage access and logging. If you treat each requirement as separate, you can end up duplicating effort and creating inconsistent controls. A better approach is to look for common control themes, such as access control, encryption, monitoring, incident response, risk management, and vendor oversight. Then you map each theme to the requirements that demand it, creating a traceable link between obligations and controls. For beginners, the point is that compliance is not about implementing one control per law; it is about building a coherent set of controls that satisfy multiple obligations simultaneously. This is also where good documentation helps, because you can show how a control supports multiple requirements without reinventing it for each one.
Privacy requirements deserve special attention because privacy is not only about security, it is also about how information is collected, used, shared, and retained. Security protects confidentiality, integrity, and availability, while privacy focuses on appropriate handling of personal information and respecting individual rights and expectations. An organization can have strong security controls and still violate privacy obligations if it collects too much data, uses it for purposes not communicated, retains it too long, or shares it improperly. Identifying privacy laws therefore involves understanding not only where data is stored, but also how it is processed and why it is processed. This includes questions about consent, transparency, lawful basis for processing, data subject access, and data deletion expectations, depending on the jurisdiction. For beginners, it helps to view privacy as a lifecycle issue, meaning you must consider the full life of the data from collection through disposal. If you only focus on protecting data from hackers, you may miss obligations about how the organization itself must behave.
Standards also play a unique role because they often provide a structured path for proving compliance to auditors and customers. In many cases, a standard includes requirements for documentation, governance, and continuous improvement, not just technical controls. That means identifying standards is also about understanding what kind of evidence the organization must produce and maintain. Evidence might include policies, risk assessments, training records, access reviews, and incident response procedures, along with technical evidence like logs and configurations. Beginners sometimes think compliance is mainly about having the right technology, but compliance often depends on proving that processes are followed and that controls are managed over time. Standards also help align different teams because they provide a shared vocabulary and a shared set of expectations. When an organization adopts a standard thoughtfully, it can reduce confusion about what good security looks like and how to demonstrate it.
A practical method for identifying applicable requirements is to build an obligation register, which is simply a structured list of what applies, why it applies, and what it requires at a high level. Each entry should include the trigger, such as industry, data type, geography, or contract, and it should note the scope, such as which business units or systems are affected. The register should also identify an owner who is responsible for monitoring changes, because laws and standards evolve and obligations can shift. This method is valuable because it turns a vague question into a manageable process. It also supports risk management, because you can see where the organization has many overlapping obligations and where gaps exist. For beginners, it helps to think of this as building a map legend before you try to navigate the terrain. Without a register, people argue about what applies based on memory and opinion, which is not a dependable way to run a security program.
Finally, identification is only valuable if it leads to translation into controls and operations. Once laws, regulations, and standards are identified, the organization must decide how to meet them in a way that is practical and integrated into daily work. This includes mapping requirements to existing controls, identifying gaps, prioritizing remediation, and defining evidence collection. It also includes training and communication so staff understand what behaviors are expected and why. A mature program does not treat compliance as a separate project that happens once; it treats compliance as part of ongoing governance and continuous improvement. For beginners, the key idea is that identifying requirements is like reading the rules of a game, but compliance is playing the game well day after day. The identification step gives you the correct rules, and the security program provides the skills and discipline to follow them consistently.
Identifying applicable security and privacy laws, regulations, and standards is a structured process of mapping organizational reality to real obligations, not an exercise in collecting impressive names. You begin by understanding triggers like industry, data types, geography, and business relationships, then scope requirements to the parts of the organization that are actually affected. You distinguish laws and regulations as mandatory legal obligations while recognizing that standards often become required through contracts and expectations, especially when evidence and audits are involved. You manage overlaps by mapping requirements to common control themes, and you treat privacy as a lifecycle discipline that includes how data is used, not only how it is protected. By maintaining an obligation register and assigning ownership for monitoring changes, the organization keeps its compliance picture current and defensible. When this identification work is translated into controls and evidence practices, it becomes a foundation for a security program that meets legal requirements, earns stakeholder trust, and avoids the costly surprise of discovering obligations only after something goes wrong.
