Governance, Risk, and Compliance Artifacts

Exam objective 5.1: Explain the importance of governance, risk, and compliance artifacts. This objective covers the documents that turn an organization's security intentions into consistent action: guidelines (benchmarks, advisories, implementation guides, and reference architectures), standards (baselines, password, physical security, RFCs, and encryption), procedures (standard operating procedures and runbooks), plans (business continuity and disaster recovery), and policies (BYOD, acceptable use, clean desk, information security, incident response, data classification and retention, access control, data disposal, vulnerability disclosure, and privacy). Collectively these are often called governance, risk, and compliance (GRC) artifacts.

This is an "explain" objective. You must understand what each type of document is, how mandatory it is, who writes and approves it, and what problem it solves. Expect questions that describe a document and ask what it is ("a step-by-step set of instructions for restoring the email server") or that describe a problem and ask which document would address it ("employees are leaving printed customer records on their desks overnight").

Governance and the Document Hierarchy

Governance is the system by which an organization is directed and controlled: who sets direction, who makes decisions, who is accountable, and how performance is monitored. Security governance ensures that the security program supports business objectives, complies with laws and regulations, and manages risk within the organization's appetite. Governance is exercised through boards, steering committees, executives such as the CISO, and—above all—through documented artifacts that tell people what is required.

GRC artifacts form a hierarchy. Each level is derived from, and must be consistent with, the level above it:

Artifact Purpose Mandator

y?

Level of detail Typical approver Change frequency

Policy States management's intent, goals, and rules (what and why)

Yes High-level, technology-neutral

Senior management or board

Rarely (reviewed annually)

Standard Specifies measurable requirements that implement policy

Yes Specific (values,

technologies)

CISO or security committee

• Occasionally
• Baseline Minimum configuration for a specific
• system type

Yes Very specific settings

Security and IT owners

When technology changes

Artifact Purpose Mandator

y?

Level of detail Typical approver Change frequency

Procedure Step-by-step instructions to perform

a task (how)

Yes, for the task

Very detailed Department or process owner

As processes change

Guideline Recommendations and best practices

No (advisory)

Variable Security team As needed

A useful example of the hierarchy in action:

• Policy: "All sensitive data must be protected with encryption in transit and at rest."
• Standard: "Data in transit must use TLS 1.2 or higher; data at rest must use AES-256."
• Baseline: "Windows Server 2025 builds must enable BitLocker with XTS-AES 256 and disable TLS 1.0 and 1.1 in Schannel."
• Procedure: "To enable BitLocker on a new server: 1. Open... 2. Select... 3. Escrow the recovery key to..."
• Guideline: "Consider using hardware security keys for administrators who travel frequently."

Figure 22.1: The GRC document hierarchy, with the encryption example traced from mandatory policy down to procedure and an optional guideline

Policies say what and why, standards say how much and with what, procedures say how, step by step, and guidelines say you should probably. Only guidelines are optional.

Exam tip

The single most tested distinction in this objective is mandatory versus optional. Policies, standards, baselines, and procedures are mandatory. Guidelines are recommendations. If a question describes a document that "suggests" or "recommends" practices, it is a guideline.

Guidelines

Guidelines are non-mandatory recommendations that help people make good decisions where strict rules would be impractical. They provide flexibility: a guideline can say "prefer" or "consider" where a standard would say "must." The objective lists four kinds of guidance documents that organizations frequently draw on.

Benchmarks

A benchmark is a consensus-based set of recommended security configuration settings for a specific product or platform. The best-known examples are the CIS Benchmarks from the Center for Internet Security, which cover operating systems, cloud platforms, databases, browsers, network devices, and more, with Level 1 (practical, low-impact) and Level 2 (defense-in-depth, may affect functionality) profiles. The US Department of Defense publishes Security Technical Implementation Guides (STIGs), which serve a similar function for government systems.

Benchmarks themselves are guidance: they are published by outside bodies and do not bind an organization. When an organization adopts a benchmark and tailors it, the result becomes its internal baseline, which is mandatory. Configuration compliance scanners (Chapter 16) can audit systems against benchmarks automatically.

Advisories

An advisory is a notice from a vendor, government agency, CERT, or ISAC describing a vulnerability, threat, or recommended action. Examples include Microsoft security update guides, CISA alerts and the Known Exploited Vulnerabilities (KEV) catalog, and vendor product security advisories. Advisories guide prioritization and response: an advisory stating that a vulnerability is being actively exploited should move it to the front of the patch queue. Chapter 20 discussed advisories as identification inputs during incident response; in a GRC context, they are inputs that drive updates to standards, baselines, and patch plans.

Implementation Guides

An implementation guide explains how to deploy or configure a product, standard, or framework correctly. Vendors publish hardening and deployment guides for their products; standards bodies publish guides explaining how to apply their frameworks (for example, NIST publishes implementation guidance for its Cybersecurity Framework, and the PCI Security Standards Council publishes guidance documents alongside PCI DSS). Implementation guides bridge the gap between "what the standard requires" and "what to actually configure."

Reference Architecture

A reference architecture is a proven, documented template for designing a solution: the components, how they connect, where security controls belong, and the design principles behind it. Examples include cloud providers' well-architected frameworks and landing-zone designs, NIST's Zero Trust architecture (SP 800-207), and vendor reference designs for secure network segmentation. Reference architectures speed design, promote consistency across projects, and reduce the risk of architects reinventing (and misdesigning) common patterns. Chapters 10 and 11 discuss architecture models in depth.

Guidance type Source Example How it is used

Benchmark CIS, DISA, vendors CIS Benchmark for Ubuntu Linux

Basis for internal configuration baselines

Advisory Vendors, CISA, CERTs, ISACs

Vendor critical patch advisory

• Prioritize patching and mitigation
• Implementation
• guide

Vendors, standards bodies

Vendor hardening guide Correctly deploy a product or framework

Reference architecture

Cloud providers, NIST, vendors

Cloud landing-zone design Template for secure system design

Standards

A standard defines specific, mandatory requirements—technologies, configurations, values, or methods —that implement policy. Standards make policies measurable and auditable. The word "standard" has two senses that the exam uses interchangeably: internal standards an organization writes for itself, and external standards published by bodies such as ISO, NIST, IETF, and PCI SSC that organizations adopt or must comply with.

Baselines

A baseline (security baseline or configuration baseline) is the documented minimum security configuration for a particular type of system—for example, every Windows 11 workstation, every Linux web server, or every cloud storage account. Baselines are usually derived from benchmarks, tailored to the organization, and enforced through Group Policy, configuration management tools, MDM, or infrastructure as code. Systems are regularly scanned for drift from the baseline. Baselines also serve as a reference for detecting unauthorized changes (Chapter 14 covers hardening, and Chapter 2 covers change management).

Figure 22.2: An external benchmark is tailored into a mandatory internal baseline that is enforced and then scanned for drift Password Standards

A password standard specifies the measurable requirements for passwords and other secrets: minimum length, complexity or composition rules, screening against breached and common passwords, reuse restrictions, lockout thresholds, storage (salted, slow hashing such as bcrypt, scrypt, PBKDF2, or Argon2), and rules for service account and shared credentials. Modern standards follow NIST SP 800-63B, which emphasizes length over complexity, recommends screening against known-compromised passwords, supports passphrases, and discourages forced periodic changes unless there is evidence of compromise. Chapter 18 covers password concepts in detail.

Physical Security Standards

A physical security standard sets requirements for protecting facilities and equipment: badge access for data centers, visitor escort and logging, camera coverage and retention periods, locks and access vestibules, environmental controls, equipment check-out, and media storage. For example: "All data center entrances must use badge plus PIN, video must be retained for 90 days, and visitors must be escorted at all times."

Rfc

A Request for Comments (RFC) is a document published by the Internet Engineering Task Force (IETF) and related bodies. Some RFCs are informational or experimental, but many define the internet's technical standards: TLS 1.3 (RFC 8446), HTTP, DNS, SMTP, Syslog (RFC 5424), IPFIX (RFC 7011), and guidance such as the evidence-collection guidelines in RFC 3227 (Chapter 21). Organizations reference RFCs in their standards to require interoperable, well-defined protocols. RFC 9116 defines security.txt, a file that tells researchers how to report vulnerabilities—relevant to the vulnerability disclosure policy later in this chapter.

Note

Do not confuse an IETF RFC with a "request for change" in change management (Chapter 2) or a "request for proposal" in vendor selection (Chapter 24). On this objective, RFC means the IETF's published technical documents.

Encryption Standards

An encryption standard specifies approved algorithms, key lengths, protocols, and key management practices. A typical encryption standard might require AES-256 for data at rest, TLS 1.2 or 1.3 for data in transit with weak cipher suites disabled, RSA keys of at least 3072 bits or elliptic curve keys of at least 256 bits, SHA-256 or stronger for hashing, keys stored in an HSM or managed key service, and defined key rotation periods. It also lists prohibited algorithms such as DES, 3DES, RC4, MD5, and SHA-1. Encryption standards increasingly address cryptographic agility and migration to post-quantum algorithms (Chapter 3). External standards such as FIPS 140-3 (validation of cryptographic modules) are often referenced.

Real-world scenario

A health technology company's encryption policy states that patient data must be encrypted. During an audit, the auditor finds that one development team used AES-128 in ECB mode while another used AES-256-GCM. Both teams believed they were compliant. The root problem was the absence of an encryption standard: the policy stated the goal, but nothing defined the approved algorithm, mode, and key length. The company publishes an encryption standard requiring AES-256-GCM and adds checks to its code review pipeline.

Procedures

A procedure is a detailed, step-by-step description of how to perform a specific task so that it is done correctly and consistently every time. Procedures implement policies and standards at the operational level and are usually owned by the team that performs the work.

Standard Operating Procedures (SOPs)

A standard operating procedure (SOP) is a formal, documented procedure for a routine operation: onboarding a new employee and provisioning accounts, offboarding and revoking access, performing backups, reviewing firewall rules, handling a request to restore a file, or sanitizing a returned laptop. SOPs reduce errors, make training easier, support separation of duties by defining who does each step, and provide evidence to auditors that processes are defined and followed.

Runbooks

A runbook is a detailed, often technical, set of instructions for executing a specific operational task or responding to a specific condition, frequently designed to be followed under pressure or executed automatically. Examples include "fail over the database cluster to the secondary region," "rotate the TLS certificate on the load balancer," or "respond to a disk-full alert on the log server." Runbooks are increasingly codified as scripts or automation workflows in orchestration and SOAR tools (Chapter 19).

Document Focus Example

SOP Routine business or IT process, done consistently Employee offboarding procedure

Runbook Specific technical operation or condition, often automatable Database failover steps Playbook Response strategy for a type of incident or scenario, may call runbooks

Ransomware response playbook

Exam tip

If the question emphasizes routine, repeatable business processes performed the same way every time, think SOP. If it emphasizes specific technical steps for an operational task or alert—especially automation—think runbook. If it emphasizes responding to a category of security incident, think playbook (Chapter 20).

Plans

Plans document how the organization will prepare for and respond to disruptions. The objective lists two.

Business Continuity Plan

A business continuity plan (BCP) describes how the organization will continue its essential business functions during and after a disruption—a pandemic, a natural disaster, a supplier failure, a ransomware attack, or loss of a facility. Business continuity is broader than IT: it covers people, facilities, processes, suppliers, and communications. A BCP typically includes:

• Scope and objectives, based on the business impact analysis (BIA) (Chapter 23), which identifies critical functions, their dependencies, and maximum tolerable downtime
• Recovery strategies for each critical function (alternate work locations, manual workarounds, alternate suppliers)
• Roles, responsibilities, and the activation and escalation process
• Communication plans for employees, customers, regulators, and the media
• Testing, training, and maintenance requirements

Continuity of operations planning (COOP) is the equivalent term used by government agencies.

Disaster Recovery Plan

A disaster recovery plan (DRP) describes how the organization will restore IT systems, data, and infrastructure after a disaster. It is a technical subset of business continuity. A DRP includes:

• Inventory of systems and their recovery priority, with recovery time objectives (RTO) and recovery point objectives (RPO)
• Backup locations, methods, and restoration procedures (Chapter 13 covers backups and site resilience)
• Alternate sites (hot, warm, cold, or cloud) and failover procedures
• Contact lists for staff, vendors, and service providers
• Step-by-step recovery runbooks and the criteria for declaring a disaster and returning to normal operations

Aspect Business continuity plan Disaster recovery plan

Question answered

How do we keep the business running? How do we restore IT systems?

Scope Entire organization: people, processes, facilities, suppliers

IT infrastructure, applications, data

Driven by BIA, critical business functions RTO and RPO for systems

Example content

Staff work from alternate office; manual order taking Restore ERP database at hot site within 4 hours

Relationship Umbrella plan Component of business continuity

Both plans must be tested (tabletop exercises, walkthroughs, simulations, parallel processing, and full failover tests are discussed in Chapter 13) and maintained: a plan with outdated contact lists or a system inventory from three years ago will fail when needed.

Business continuity is about the business; disaster recovery is about IT. If a question describes keeping customer service operating by having employees work from home during a building closure, that is business continuity. If it describes bringing servers online at a secondary data center, that is disaster recovery.

Policies

A policy is a high-level statement of management's intent, expectations, and rules. Policies are mandatory, are approved by senior management, apply broadly, and generally avoid naming specific technologies so that they remain valid as technology changes. They establish authority: a security team can enforce a standard because a policy approved by leadership requires it. Good policies define their purpose, scope, roles and responsibilities, the policy statements themselves, compliance and enforcement (consequences of violation), exceptions process, and review cycle.

The SY0-801 objective lists ten policies.

Information Security Policy

The information security policy is the top-level security policy, sometimes called the enterprise or organizational security policy. It establishes the security program, states management's commitment, defines the program's scope and objectives, assigns roles and responsibilities (board, executives, CISO, data owners, users), references the subordinate policies and standards, and grants the authority to enforce them. Every other security policy derives from it. It is typically approved by the board or the CEO and reviewed at least annually.

Acceptable Use Policy (AUP)

The acceptable use policy (AUP) defines what users may and may not do with the organization's IT resources: computers, networks, email, internet access, cloud services, and data. It typically addresses personal use, prohibited activities (harassment, illegal downloads, unauthorized software, attempts to bypass controls), monitoring and the lack of privacy expectation on company systems, and consequences for violations. Users typically acknowledge the AUP at onboarding and annually, and many systems display a login banner referencing it. The AUP provides the legal basis for monitoring and for disciplinary action.

Bring Your Own Device (BYOD) Policy

A BYOD policy governs the use of personally owned devices—phones, tablets, laptops—to access organizational resources. It addresses eligibility, required security controls (screen lock, encryption, current OS, MDM or MAM enrollment), separation of personal and corporate data (containerization), the organization's right to remotely wipe corporate data (and whether it may wipe the whole device), privacy limits on what the organization can see, support responsibilities, reimbursement, and what happens when the device is lost or the employee leaves. Chapter 14 compares deployment models such as BYOD, COPE, and CYOD.

Clean Desk Policy

A clean desk policy requires employees to secure sensitive information when they leave their workspace: locking papers, notes, and removable media in drawers or cabinets, collecting printouts promptly, locking screens, not writing passwords on sticky notes, and clearing whiteboards after meetings. It reduces the risk of information being viewed or taken by visitors, cleaning crews, other employees, or intruders, and it supports privacy compliance.

Incident Response Policy

The incident response policy establishes the organization's commitment to incident response and gives the program its authority. It defines what constitutes an incident, the scope of the policy, the formation and authority of the incident response team (including authority to disconnect systems), reporting requirements for employees, severity classification, and requirements for the incident response plan, communications, and post-incident review. The detailed processes live in the incident response plan and playbooks (Chapter 20); the policy states that they must exist and who owns them.

Data Classification and Retention Policy

The data classification portion of this policy defines sensitivity levels (for example, Public, Internal, Confidential, Restricted; or government levels such as Unclassified, Secret, Top Secret), the criteria for assigning each level, the roles responsible (data owners classify; custodians protect), and the handling requirements for each level—labeling, encryption, sharing, storage, and transmission. Chapter 12 covers data types and classifications in detail.

The retention portion defines how long each category of data must be kept and when it must be destroyed. Retention periods are driven by legal and regulatory requirements (tax records, healthcare records, financial transaction logs), business needs, and privacy principles that require personal data not be kept longer than necessary. Retention must be suspendable by a legal hold when litigation is anticipated (Chapter 25). Keeping data too long increases breach exposure and e-discovery cost; deleting it too soon can violate laws.

Access Control Policy

The access control policy defines how access to systems and data is granted, reviewed, and revoked. It establishes principles such as least privilege, need to know, and separation of duties (Chapter 1); requirements for account provisioning approval, authentication strength (for example, MFA for remote and privileged access), privileged access management, periodic access reviews and recertification, shared and service account rules, and timely deprovisioning on termination or role change. Chapter 18 covers access control models that implement this policy.

Data Disposal Policy

The data disposal policy defines how data and media are destroyed at the end of their retention period or service life so that information cannot be recovered. It specifies approved sanitization methods by media type and classification—following guidance such as NIST SP 800-88 (clear, purge, destroy)— including overwriting, cryptographic erasure, degaussing (magnetic media only), shredding, pulverizing, and incineration; requirements for certificates of destruction from disposal vendors; and handling of paper records. Chapter 15 covers asset disposal and sanitization.

Vulnerability Disclosure Policy

A vulnerability disclosure policy (VDP) tells external security researchers how to report vulnerabilities they find in the organization's products or systems, what systems are in scope, what testing is permitted, how quickly the organization will respond, and—critically—a safe harbor commitment not to pursue legal action against good-faith researchers who follow the policy. A VDP is often published at /.well-known/security.txt (RFC 9116). It may be paired with a bug bounty program that pays rewards. Internally, a VDP also governs how the organization coordinates disclosure of vulnerabilities in its own products to customers. Chapter 16 discusses responsible disclosure and bug bounties.

Privacy Policy

A privacy policy describes how the organization collects, uses, shares, stores, and protects personal information. There are two audiences:

• An external privacy policy (privacy notice) informs customers and website visitors what data is collected, why, the legal basis, with whom it is shared, how long it is kept, and how individuals can exercise their rights (access, correction, deletion, opt-out). Laws such as GDPR, PIPEDA, and the California Consumer Privacy Act (CCPA, as amended by the CPRA) require such notices.
• An internal privacy policy directs employees on how to handle personal data in line with those commitments and legal requirements.

Chapter 25 covers privacy concepts such as data subject rights, controllers, and processors.

• Policy Problem it addresses
• Information security Establishes the program, authority, and roles
• Acceptable use Misuse of organizational IT resources
• BYOD Security and privacy of personal devices accessing corporate data
• Clean desk Sensitive information left exposed in workspaces
• Incident response Authority and requirements for handling incidents
• Policy Problem it addresses

Data classification and retention

• Inconsistent protection; keeping data too long or too briefly
• Access control Excessive or unreviewed access
• Data disposal Recoverable data on discarded media

Vulnerability disclosure No safe channel for researchers to report flaws Privacy Collection and use of personal data

Real-world scenario

A security researcher discovers that a retailer's customer portal exposes order records through a predictable URL. Unable to find a contact, she posts about it on social media, and the company learns of the issue at the same time as attackers. A month later the company publishes a vulnerability disclosure policy with a security.txt file, a monitored reporting address, a defined scope, a 5-business-day acknowledgment commitment, and safe harbor language. The next researcher who finds a flaw reports it privately.

Why GRC Artifacts Matter

GRC artifacts can feel like paperwork, but they produce real security outcomes:

• Consistency: documented standards and procedures mean that the hundredth server is configured as securely as the first, regardless of who builds it.
• Accountability: documents assign owners and responsibilities. When something goes wrong, it is clear who was responsible for what.
• Enforcement and legal defensibility: an organization cannot reasonably discipline an employee for violating a rule that was never documented or acknowledged. Signed AUP acknowledgments support disciplinary and legal action.
• Compliance evidence: auditors and regulators ask first for policies and procedures, then test whether practice matches them (Chapters 25 and 26). Demonstrating due care (doing what a reasonable organization would) and due diligence (investigating and maintaining controls) depends on documentation.
• Training foundation: awareness programs (Chapter 27) teach the content of policies.
• Resilience: plans and runbooks allow people other than the original expert to recover systems at 3:00 a.m.

Document Life Cycle

GRC artifacts must be managed through a life cycle:

• 1. Draft with input from stakeholders (security, IT, legal, HR, business units).
• 2. Review and approve at the right level of authority—policies by senior management, standards by the security function, procedures by process owners.
• 3. Publish and communicate to the people who must follow them, with acknowledgment where appropriate.
• 4. Implement and enforce through technical controls, training, and monitoring.
• 5. Review periodically (commonly annually) and after significant events: a major incident, a new regulation, an audit finding, a merger, or a technology change.
• 6. Manage exceptions through a formal process in which a business owner requests a documented, time-limited exception, risk is assessed, compensating controls are defined, and an authorized manager accepts the risk (Chapter 23 covers risk acceptance).
• 7. Retire obsolete documents under version control so that the current version is always clear.

Figure 22.3: The GRC document life cycle, including review triggers, exceptions, and retirement

Common trap

A policy that is written but never communicated, enforced, or reviewed provides little protection and can even create liability, because it shows the organization knew what it should do and did not do it. Look for answers that include communication, acknowledgment, and periodic review.

When an exam scenario says a policy is "outdated" or "no longer reflects current practices," the answer usually involves a periodic review process. When it says staff "were unaware" of a rule, the answer usually involves communication, training, and signed acknowledgments.

Chapter Summary

• GRC artifacts form a hierarchy: policies (what and why, mandatory, high-level), standards (specific mandatory requirements), baselines (minimum configurations), procedures (step-by-step how), and guidelines (optional recommendations).
• Guidelines include benchmarks (CIS Benchmarks, STIGs), advisories (vendor, CISA, ISAC notices), implementation guides, and reference architectures.
• Standards include baselines, password standards (NIST SP 800-63B), physical security standards, IETF RFCs, and encryption standards (approved algorithms, key lengths, FIPS 140-3).
• Procedures include SOPs for routine processes and runbooks for specific, often automated, technical operations.
• The business continuity plan keeps the business running; the disaster recovery plan restores IT systems and is a subset of continuity planning.
• Key policies: information security (top-level), AUP, BYOD, clean desk, incident response, data classification and retention, access control, data disposal, vulnerability disclosure (with safe harbor and security.txt), and privacy.
• Artifacts provide consistency, accountability, enforceability, compliance evidence, and resilience— but only if they are communicated, acknowledged, enforced, and reviewed regularly.

Key Terms

Governance; GRC; policy; standard; baseline; procedure; guideline; benchmark; CIS Benchmarks; STIG; advisory; Known Exploited Vulnerabilities catalog; implementation guide; reference architecture; configuration drift; password standard; NIST SP 800-63B; physical security standard; Request for Comments (RFC); IETF; security.txt; encryption standard; FIPS 140-3; cryptographic agility; standard operating procedure (SOP); runbook; playbook; business continuity plan (BCP); continuity of operations (COOP); disaster recovery plan (DRP); business impact analysis; RTO; RPO; information security policy; acceptable use policy (AUP); BYOD policy; clean desk policy; incident response policy; data classification policy; data retention policy; legal hold; access control policy; data disposal policy; NIST SP 800-88; certificate of destruction; vulnerability disclosure policy (VDP); safe harbor; bug bounty; privacy policy; privacy notice; due care; due diligence; policy exception.

Review Questions

• 1. A document published by the security team states that employees "should consider" using a password manager and "are encouraged" to enable MFA on personal accounts. What type of document is this?

• A. Policy
• B. Standard
• C. Guideline
• D. Procedure

• 2. A company adopts the CIS Benchmark for Windows 11, removes two settings that break a critical application, and requires all workstations to match the resulting configuration. What is the resulting document?

• A. Advisory
• B. Baseline
• C. Reference architecture
• D. Privacy policy

• 3. Auditors found that different development teams used different encryption algorithms and key lengths, all believing they satisfied the policy requirement to "encrypt sensitive data." Which artifact should be created to correct this?

• A. Encryption standard
• B. Clean desk policy
• C. Business continuity plan
• D. Vulnerability disclosure policy

• 4. A facilities manager notices that printed customer records and sticky notes containing passwords are routinely left on desks overnight. Which policy BEST addresses this issue?

• A. Acceptable use policy
• B. Data disposal policy
• C. Clean desk policy
• D. BYOD policy

• 5. An operations team documents the exact technical steps to fail over its database cluster to a secondary region, and converts the steps into an automated workflow. What is this document?

• A. Runbook
• B. Policy
• C. Benchmark
• D. Business continuity plan

• 6. During a regional flood, a company's customer service staff work from a partner's office and take orders manually while systems are unavailable. Which plan is being executed?

• A. Disaster recovery plan
• B. Business continuity plan
• C. Incident response plan
• D. Data retention plan

• 7. A security researcher wants to report a vulnerability in a company's web application but fears legal action. Which TWO elements of a vulnerability disclosure policy address this? (Select TWO.)

• A. Safe harbor commitment for good-faith research
• B. A published security.txt file with reporting contact details
• C. An acceptable use policy for employees
• D. A data classification scheme
• E. A clean desk requirement

• 8. Which of the following documents is the top-level document that establishes an organization's security program, assigns roles, and grants authority to enforce subordinate policies?

• A. Information security policy
• B. Acceptable use policy
• C. Standard operating procedure
• D. Implementation guide

• 9. A company's policy states that personal phones may access corporate email only if enrolled in MDM, and that the company may remotely wipe the corporate container. Which policy is this?

• A. Access control policy
• B. BYOD policy
• C. Privacy policy
• D. Data disposal policy

• 10. An organization keeps every email ever sent, which increased its costs significantly during a recent lawsuit's e-discovery. Which policy should be revised?

• A. Data classification and retention policy
• B. Incident response policy
• C. Clean desk policy
• D. Encryption standard

• 11. Which of the following are mandatory GRC artifacts? (Select TWO.)

• A. Guidelines
• B. Standards
• C. Procedures
• D. Advisories
• E. Reference architectures

• 12. A government agency publishes a notice stating that a vulnerability in a widely used VPN appliance is being actively exploited and recommends immediate patching. A company uses this notice to reprioritize its patch schedule. What type of artifact is the notice?

• A. Benchmark
• B. Advisory
• C. Baseline
• D. Runbook

Answers and Explanations

• 1. C. Language such as "should consider" and "are encouraged" indicates a recommendation, which is a guideline. Policies, standards, and procedures are mandatory and use "must" or "shall" language.
• 2. B. A benchmark tailored and mandated as the minimum configuration for a system type becomes a baseline. An advisory announces a threat or vulnerability, a reference architecture is a design template, and a privacy policy addresses personal data.
• 3. A. The policy states the goal but does not specify how; an encryption standard defines approved algorithms, modes, and key lengths so implementations are consistent. The other documents do not address cryptographic requirements.
• 4. C. A clean desk policy requires securing papers, media, and credentials when a workspace is unattended. The AUP governs use of IT resources, the data disposal policy governs destruction, and BYOD covers personal devices.
• 5. A. Runbooks contain specific technical steps for operational tasks and are often automated. A policy is high-level intent, a benchmark is recommended configuration, and a BCP covers the continuity of business functions broadly.
• 6. B. Keeping business functions operating through alternate locations and manual workarounds is business continuity. Disaster recovery focuses on restoring IT systems. The incident response plan addresses security incidents, and there is no standard "data retention plan" in this context.
• 7. A, B. Safe harbor language assures researchers that good-faith reports will not result in legal action, and security.txt tells them how to report. An AUP, data classification, and clean desk rules govern internal behavior and data, not external reporting.
• 8. A. The information security policy is the top-level policy that establishes the program and its authority. The AUP is a subordinate policy for user behavior, an SOP describes how to perform tasks, and an implementation guide is guidance.
• 9. B. Rules for personally owned devices, including MDM enrollment and remote wipe, belong in a BYOD policy. The access control policy governs granting and reviewing access generally, the privacy policy covers personal data, and data disposal covers destruction.
• 10. A. A retention policy defines how long data is kept and when it is destroyed; keeping data indefinitely increases e-discovery cost and breach exposure. The other documents do not set retention periods.
• 11. B, C. Standards and procedures are mandatory. Guidelines are recommendations, and advisories and reference architectures are guidance inputs that organizations may choose to adopt.
• 12. B. A notice from a government agency or vendor describing a vulnerability or threat and recommending action is an advisory. A benchmark is a set of configuration recommendations, a baseline is an internal minimum configuration, and a runbook is a set of operational steps.