Episode 5 — Glossary of common cybersecurity terms

As cybersecurity practices mature, professionals encounter more specialized terminology that connects operational tactics to governance and technical architecture. Multi-Factor Authentication (MFA) enhances login security by requiring two or more proofs of identity—something you know, have, or are. Encryption transforms readable data into a coded form to protect its confidentiality both in transit and at rest. Patch management refers to the continuous process of applying vendor updates to eliminate known vulnerabilities, while configuration management ensures that systems maintain secure, documented baselines. Endpoint Detection and Response (EDR) describes technology that monitors devices for malicious behavior, supplementing traditional anti-malware defenses. In network contexts, terms like Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) denote mechanisms that identify and stop unauthorized activity. Meanwhile, SIEM—Security Information and Event Management—aggregates and correlates logs from across the enterprise to detect anomalies and support investigations.

Beyond technology, the CIS Controls frequently reference governance-related terms. Implementation Group (IG) defines which safeguards apply based on organizational maturity, while risk assessment quantifies exposure and prioritizes remediation. Data classification determines how information is labeled and protected according to sensitivity, whereas data loss prevention (DLP) solutions automatically monitor and restrict unauthorized transfers. Incident response plan (IRP) outlines roles, responsibilities, and communication procedures during cyber events. Zero trust represents a modern design principle assuming no implicit trust between users or systems, enforcing continuous verification at every layer. Together, these advanced concepts give depth and precision to operational cybersecurity, bridging the gap between compliance and active defense. Mastery of this language allows professionals to interpret frameworks, communicate findings, and implement controls confidently across technical and managerial domains.
Produced by BareMetalCyber.com, where you’ll find more cyber audio courses, books, and information to strengthen your educational path. Also, if you want to stay up to date with the latest news, visit DailyCyber.News for a newsletter you can use, and a daily podcast you can commute with.

Episode Transcript

(00:00):
Welcome to Episode 5, Policies, Standards, and Procedures that Support CIS 18, where we turn from inventories and scope toward the written framework that holds a cybersecurity program together. The documents that define governance—your policies, standards, and procedures—give structure to everything that follows. They clarify expectations, set limits, and demonstrate to auditors that actions are not random but guided by a deliberate system of control. Without these documents, the CIS Controls remain a checklist; with them, they become a living program. This episode explains how to create and maintain governance documentation that is right-sized for your organization and aligned with the CIS Controls.

(00:44):
Governance documents matter because they convert intentions into enforceable commitments. In daily operations, many good security practices happen informally—an administrator locks a device, a team applies updates—but auditors and regulators require written proof that these behaviors are defined, repeatable, and approved. Policies and standards also help employees make decisions without constant supervision. When guidance is clear, people can act confidently, knowing what is required and what is prohibited. For leadership, these documents represent assurance; for staff, they are guardrails that keep actions consistent and defensible.

A policy, a standard, and a procedure serve distinct but connected purposes. A policy states the rule or principle, such as “All systems must be protected by multi-factor authentication.” A standard defines the measurable requirement that enforces that policy, such as specifying which authentication methods are approved. A procedure describes how to carry out the task—step-by-step instructions for enabling multi-factor authentication on a specific system. This hierarchy keeps documents manageable (01:22):
policies explain why, standards explain what, and procedures explain how. Understanding these differences prevents overlap and ensures each document stays focused and useful.

(02:05):
Certain policies directly support the CIS Controls. For example, an Asset Management Policy supports Controls One and Two by requiring inventories of hardware and software. An Access Control Policy supports Controls Five and Six by defining how accounts are created and reviewed. A Data Protection Policy underpins Control Three, while an Incident Response Policy aligns with Control Seventeen. Together, these core policies form the governance backbone of a CIS program. Each policy should map to specific controls and include references so that assessors can trace compliance easily.

(02:42):
Standards translate policy statements into consistent behavior across systems and teams. They specify configurations, technologies, and settings that must be used. For instance, a password standard might require minimum length, complexity, and rotation frequency. A configuration standard might require disabling default accounts or enforcing encryption. Standards remove ambiguity and make security measurable. They also enable automation—when requirements are clear and repeatable, tools can check compliance and alert teams to drift. This discipline ensures that security does not depend on memory or personal preference.

(03:21):
Procedures carry those standards into daily action. Each procedure identifies the responsible owner, the specific steps, and the frequency of execution. For example, a patch management procedure might describe how to review vulnerability reports weekly and how to approve updates through a change process. Clarity about ownership prevents confusion when people change roles or when auditors ask who performs a control. Good procedures are detailed enough for consistency but not so rigid that they become unusable. They should describe the desired outcome and the sequence of tasks that achieve it.

(03:55):
Version control and approval workflows keep governance documents trustworthy. Each document should have an author, an approver, and a version history showing when it was last updated. A central repository—whether a document management system or a shared drive—should maintain only the current approved version. Changes should follow a review cycle with signatures or electronic approvals. This structure ensures that everyone follows the same guidance and that no outdated versions linger. In audits, version control demonstrates maturity and prevents disputes about which policy was active at a given time.

(04:31):
Distribution, acknowledgment, and training turn documents into practice. Once a policy is approved, staff must receive it, read it, and confirm understanding. This acknowledgment can be electronic, such as a checkbox in a learning system. Training reinforces comprehension, using examples relevant to daily work. For instance, password guidance should appear in onboarding materials, and incident reporting instructions should appear in employee orientation. Awareness ensures that governance documents do not sit unused but actively shape behavior across the enterprise.

(05:07):
Even with strong governance, exceptions and temporary deviations will arise. Systems may need outdated software to support legacy operations, or urgent business needs may require delayed updates. An exception process allows these deviations under controlled conditions. Requests should describe the risk, compensating controls, expiration date, and approval authority. Tracking exceptions shows that management is aware of risks and taking measured steps to address them. Without such a process, unapproved deviations accumulate silently, weakening the integrity of the program.

(05:45):
Templates and style guidance make documentation efficient and readable. Every policy or procedure should share a common format with sections for purpose, scope, responsibilities, references, and revision history. Consistency reduces confusion and speeds up reviews. Style guidance should favor plain language over jargon, using short sentences and active voice. A good test is whether someone new to the organization could read the document and apply it correctly. Clear structure and tone make governance accessible rather than intimidating.

(06:19):
Targeting the right audience is equally important. Not every employee needs to see every detail. Technical standards can live in administrator guides, while high-level policies belong in employee handbooks. Tailoring content prevents overload and ensures that each reader receives only what they need to follow. Using plain language broadens understanding across departments, making security a shared responsibility rather than a specialist’s domain. Simplicity helps people remember and apply rules accurately.

(06:50):
Evidence artifacts should be linked and referenced directly in the documents. For example, a backup policy might cite where logs are stored and who reviews them. Embedding these references turns governance documents into living indexes that connect policies to real operational data. When auditors review them, they can trace each statement to supporting evidence. This approach saves time and reinforces that policies are not aspirational—they are backed by verifiable activity within the organization.

(07:20):
Periodic reviews and sunset decisions keep documentation relevant. Every policy should have a scheduled review date, typically annual, and an assigned reviewer. If a policy no longer applies, retire it formally rather than letting it fade into neglect. Sunset procedures remove obsolete content and prevent confusion. Each review should consider new technologies, regulatory changes, and lessons learned from incidents. A culture of review demonstrates adaptability and continuous improvement, core values of the CIS framework.

For small teams starting out, a quick-start set of documents can be created with minimal effort (07:53):
an Information Security Policy, Access Control Policy, Data Protection Policy, and Incident Response Plan. These four cover most of the CIS Controls at a foundational level. Over time, additional standards and procedures can be added as the program matures. Starting simple encourages participation and builds confidence that governance can be manageable, not burdensome.

(08:21):
By establishing policies, standards, and procedures that align with CIS 18, you give your program stability and clarity. Governance documents translate security intentions into repeatable actions and verifiable results. They guide people, anchor audits, and ensure accountability across every control. In the next stage of this course, we will build on this foundation by connecting these written frameworks to technical operations—showing how each control transforms from words on paper into measurable security in practice.