Cyber Security Quiz: Security Policies And Standards
10 questions · exam conditions
0:00
Security Policies And StandardsQuestion 1 of 10

A company's internal security policy requires prompt revocation of access when personnel leave. A cloud service provider administers its own support accounts that can access the company's data. The provider's standard contract contains only a general promise to use reasonable security and does not reference access-revocation timing.

Which action most effectively extends the intended requirement to the provider?

Send the internal policy document to the provider, because distributing it to external parties makes all internal requirements contractually binding on them
Ask the provider to adopt the company's entire internal policy hierarchy, without specifying which controls apply to the services being delivered
Issue an internal procedure directing company employees to revoke the provider's support accounts, even though only the provider has administrative control over those accounts
Add a contractual control requirement specifying revocation timing, the evidence the provider must supply to demonstrate compliance, and each party's responsibilities
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Security Policies And Standards

Practice Security Policies And Standards in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Security Policies And Standards, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A company's internal security policy requires prompt revocation of access when personnel leave. A cloud service provider administers its own support accounts that can access the company's data. The provider's standard contract contains only a general promise to use reasonable security and does not reference access-revocation timing.

Which action most effectively extends the intended requirement to the provider?

  1. Send the internal policy document to the provider, because distributing it to external parties makes all internal requirements contractually binding on them
  2. Ask the provider to adopt the company's entire internal policy hierarchy, without specifying which controls apply to the services being delivered
  3. Issue an internal procedure directing company employees to revoke the provider's support accounts, even though only the provider has administrative control over those accounts
  4. Add a contractual control requirement specifying revocation timing, the evidence the provider must supply to demonstrate compliance, and each party's responsibilities (correct answer)
Explanation: When a third-party provider controls access to your company's data, your internal policies alone carry no legal weight unless they are formally embedded in the contract. This question tests whether you understand how to extend security controls across organizational boundaries — a core concept in third-party risk management and supply chain security. The most effective mechanism is what option D describes: a contractual clause that specifies exactly what is required (revocation timing), how compliance is demonstrated (required evidence), and who is responsible for what. This creates enforceable obligations, an audit trail, and clear accountability — the three pillars of effective third-party control extension. Because the provider manages its own support accounts, the company cannot unilaterally enforce revocation; the requirement must be baked into the agreement itself. Option A reflects a common misconception — simply sharing an internal document with an external party does not make it binding. Contracts require mutual agreement, consideration, and specificity. Forwarding a PDF accomplishes none of that. Option B is a trap for overcorrection: asking a provider to adopt your entire policy hierarchy without scoping it to relevant services creates ambiguity, likely non-compliance, and negotiation friction. Vague requirements are nearly impossible to enforce. Option C is perhaps the most dangerous distractor because it sounds procedural and official, but it assigns responsibility to employees who literally lack the technical access to carry it out — a control with no teeth. As a study tip: whenever a question involves third-party obligations, ask yourself whether the mechanism described is enforceable and verifiable. Internal memos and goodwill promises never are — contracts with specific, measurable requirements always are.

Question 2

After an acquisition, a subsidiary adopts the parent company's governance hierarchy. The corporate data-classification policy requires information to be classified when created. A subsidiary standard still permits new files to remain unclassified for up to 30 days. No law or contractual obligation requires the delayed classification period.

What is the most appropriate governance response to the inconsistency?

  1. Retain the subsidiary standard because operational standards are more specific and therefore supersede corporate policies
  2. Convert the corporate policy into a guideline so each subsidiary can select its own classification timing
  3. Allow the conflict until the next scheduled policy review because acquired documents remain independently authoritative
  4. Revise the subsidiary standard or obtain a formally approved, risk-based exception to the corporate policy (correct answer)
Explanation: When you see a question about policy conflicts after a corporate acquisition, think about governance hierarchy: corporate policies sit above subsidiary standards, and conflicts must be resolved — not tolerated or worked around by weakening the higher-level document. In a proper governance hierarchy, corporate policy is authoritative. When a subsidiary standard contradicts it — here, by allowing a 30-day window that the corporate policy forbids — the subsidiary standard must either be revised to align or formally suspended through a documented, risk-based exception process. That exception process exists precisely for situations where operational reality creates a legitimate temporary gap, but it requires explicit approval, not passive coexistence. Answer D captures both remediation paths correctly: fix the standard or get a sanctioned exception. Answer A gets the hierarchy backwards. Specificity does not grant a lower-tier document authority to override a higher-tier one. Operational standards elaborate on policy; they cannot contradict it. Answer B undermines the entire purpose of a corporate policy by converting it into a guideline, which is advisory rather than mandatory — this would effectively eliminate the control organization-wide, which is a disproportionate and dangerous response to a single subsidiary conflict. Answer C is particularly tempting but wrong: acquired documents do not remain "independently authoritative" after the governance hierarchy has been formally adopted. Waiting for a scheduled review while a known, unresolved conflict exists is a governance failure, not a strategy. A useful rule of thumb: whenever a lower-tier document conflicts with a higher-tier one, the answer will almost never be "let it ride" or "weaken the higher document." Expect the correct response to involve alignment, escalation, or a formal exception with documented approval.

Question 3

A board-approved document titled "Privileged Access Policy" contains exact command-line instructions for creating an administrator account, required screenshots for each workflow step, and a troubleshooting sequence. It does not state organizational objectives or general access-control principles.

How should the document be classified based primarily on its function?

  1. As a policy, because approval by the board determines the document type regardless of its content
  2. As a procedure, because it provides repeatable, step-by-step instructions for performing a specific task (correct answer)
  3. As a standard, because command syntax represents a mandatory technical baseline for all administrators
  4. As a guideline, because troubleshooting information gives administrators discretion when commands do not work
Explanation: When classifying security documentation, focus on what the document does, not what it's called or who approved it. The four document types — policy, standard, procedure, and guideline — each serve a distinct function, and exam questions will often include deliberate distractors that confuse naming conventions with actual content. A procedure is defined by its operational nature: it provides sequential, repeatable steps that tell someone how to perform a specific task. The document here contains exact command-line syntax, required screenshots at each step, and a troubleshooting sequence — all hallmarks of procedural content. That makes B the correct classification. The document isn't communicating organizational intent; it's walking an administrator through an action from start to finish. A is a classic trap. Board approval is a governance mechanism, not a content classifier. A board can approve a procedure, a standard, or a guideline — approval authority says nothing about document type. Don't let titles or approval chains override what the content actually does. C misidentifies the command syntax as a "standard." Standards define mandatory technical baselines (e.g., "all passwords must be 12 characters"), but they don't walk you through how to implement them step by step. The presence of syntax alone doesn't make something a standard. D misreads what troubleshooting content means. A guideline offers flexible, discretionary recommendations. Troubleshooting steps within a procedure are still procedural — they guide the administrator through a specific failure scenario, not open-ended judgment calls. Your study tip: on exam questions about document classification, always ask "What does this document do?" — objectives → policy, mandatory baselines → standard, step-by-step tasks → procedure, flexible recommendations → guideline.

Question 4

During an account-recovery incident, service desk personnel followed an approved procedure that instructed them to accept knowledge-based questions as sole identity proof. A recently updated identity standard requires two independent verification methods. The policy's high-level requirement for verified account recovery remains valid.

What is the most appropriate document-control response after containing the incident?

  1. Revert the identity standard because personnel complied with the previously approved recovery procedure
  2. Withdraw or correct the conflicting procedure, communicate the change, and verify alignment with the standard (correct answer)
  3. Replace the identity policy with detailed service desk scripts to prevent future interpretation differences
  4. Keep both documents active but publish a guideline advising personnel to select the safer requirement
Explanation: When you see a document-control question involving a conflict between a policy and a procedure, your job is to identify the correct hierarchical relationship: policies set requirements, and procedures must align with them — not the other way around. In this scenario, the procedure is outdated. It allows single-factor knowledge-based verification, but the updated identity standard now mandates two independent methods. The high-level policy goal (verified account recovery) remains sound — only the procedure has fallen out of compliance. The correct document-control response is B: withdraw or correct the conflicting procedure, communicate the change to affected personnel, and confirm the updated procedure aligns with the current standard. This follows the fundamental principle that lower-level operational documents must always be subordinate to and consistent with governing standards. A gets the hierarchy backwards. Reverting the standard to excuse compliant-but-outdated procedure behavior would weaken security controls to match a flawed process — exactly the wrong direction. You never downgrade a valid policy to protect a broken procedure. C replaces the wrong document. The identity policy is explicitly stated to still be valid, so replacing it with scripts is unnecessary and would eliminate important strategic guidance in favor of rigid tactical instructions, reducing flexibility without fixing the root cause. D is a common trap: keeping conflicting documents active while issuing a "choose the safer one" guideline creates ambiguity and puts the burden of judgment on frontline personnel. This is poor document governance and an audit failure waiting to happen. Your study tip: whenever a question involves conflicting documents, ask yourself which document is wrong and who owns the fix. Procedures serve policies — always resolve conflicts by correcting the lower-level document.

Question 5

An organization's draft security policy states, "System owners should protect sensitive data using appropriate controls." Different departments interpret this statement differently, and auditors cannot determine whether nonconforming systems violate the policy. Management intends protection of sensitive data to be mandatory.

Which revision would best improve enforceability without placing excessive technical detail in the policy?

  1. State the mandatory protection outcome using "must," then define measurable control requirements in supporting standards (correct answer)
  2. Retain "should," then add detailed configuration commands directly to the policy for every supported platform
  3. Replace the statement with optional guidelines so departments can select controls based solely on local preferences
  4. Move the entire requirement into procedures so administrators can determine whether protection is necessary per system
Explanation: When you see a question about security policy design, think about the classic policy-standard-procedure hierarchy. Policies express what must be achieved (outcomes), standards define how it's measured (requirements), and procedures explain how to implement it (technical steps). Enforceability depends on clear, mandatory language at the right level of this hierarchy. The core problem here is twofold: the word "should" signals optionality rather than obligation, and the requirement lacks measurable criteria auditors can verify. Option A fixes both issues elegantly — replacing vague language with "must" establishes a binding obligation, while pushing measurable control requirements into supporting standards keeps the policy itself clean and platform-agnostic. Auditors can now confirm compliance against specific, documented standards without the policy becoming a technical manual. This is exactly how mature frameworks like NIST and ISO 27001 are structured. Option B is a trap that overcorrects — embedding detailed configuration commands directly into a policy violates the hierarchy principle. Policies become instantly outdated whenever platforms change, and they balloon into unmanageable documents. Option C moves in the wrong direction entirely: making protection optional contradicts management's intent that it be mandatory and eliminates any basis for enforcement. Option D also misplaces content — moving the requirement entirely into procedures hands discretion to individual administrators to decide whether protection is even necessary, which removes the organizational mandate altogether and makes compliance impossible to audit consistently. Study tip: On security exam questions involving policy language, always ask yourself three things — Is the obligation mandatory or optional? Is the outcome measurable? Is technical detail placed at the appropriate tier? Those three checks will guide you to the right answer.

Question 6

Employees sometimes work remotely from locations with unreliable connectivity. The organization already requires encrypted remote connections and managed endpoints. Security wants to publish nonmandatory advice about choosing private workspaces, positioning screens, and using mobile hotspots when appropriate. The advice must allow employees to adapt to local circumstances.

Which type of document is most appropriate for this new material?

  1. A policy defining executive intent and mandatory organization-wide remote-access outcomes
  2. A standard prescribing uniform technical configurations that every remote worker must implement
  3. A guideline presenting recommended practices that users may adapt to situational conditions (correct answer)
  4. A procedure prescribing a fixed sequence that users must complete during every remote session
Explanation: When cybersecurity questions ask about documentation types, your first move should be identifying the binding force of the document: is it mandatory or advisory, uniform or flexible? The hierarchy runs policy → standard → guideline → procedure, and each serves a distinct purpose. Here, the scenario signals three critical clues: the advice is "nonmandatory," it covers situational topics like screen positioning and workspace choice, and it must "allow employees to adapt." That profile perfectly matches a guideline — a document that offers recommended practices without imposing rigid requirements. Guidelines acknowledge that real-world conditions vary and trust users to apply good judgment, which is exactly what remote workers need when connectivity and physical environments differ by location. C is the correct answer. A is wrong because a policy articulates executive-level mandatory intent and organizational outcomes — it establishes what must be achieved, not flexible situational advice. Publishing optional screen-positioning tips as a policy would misrepresent their authority level and create confusion about what's actually required. B is wrong because a standard prescribes specific, uniform technical configurations that everyone must follow — think password length minimums or encryption cipher requirements. The passage explicitly says the new material is nonmandatory and adaptable, which is the opposite of what a standard does. D is wrong because a procedure defines a fixed, step-by-step sequence that must be followed every time — like a login checklist or incident response runbook. Procedures leave no room for situational adaptation, directly contradicting the scenario's flexibility requirement. Your study tip: memorize the mandatory/flexible axis for each document type. Policy and standards = mandatory; guidelines and procedures differ in that procedures are mandatory sequences while guidelines are optional recommendations.

Question 7

An organization's access-control policy requires multifactor authentication for all administrative access. Its authentication standard lists push notifications and time-based one-time passwords as the only approved second factors. Enrollment procedures provide steps only for those two methods. The security team has validated a phishing-resistant passkey implementation and wants to authorize it across the organization.

Which document should be revised first to establish that passkeys are an approved implementation of the existing policy?

  1. The access-control policy, because it must identify every authentication factor authorized for administrative use
  2. The authentication standard, because it defines the mandatory technologies permitted to satisfy the policy (correct answer)
  3. The enrollment procedure, because adding implementation steps automatically makes the new factor organization-wide
  4. The authentication guideline, because recommended technologies take precedence when the policy is technology-neutral
Explanation: When organizations build security programs, they layer documents by authority: policies set what must happen, standards define how it must happen (with specific, mandatory technologies), procedures describe step-by-step implementation, and guidelines offer optional recommendations. This hierarchy is what the question is really testing. The authentication standard is the right place to start because it's the document that enumerates which specific technologies are required to satisfy the policy's MFA mandate. Right now the standard lists only push notifications and TOTPs as approved second factors. Passkeys don't exist in that list, so no one can legitimately use them — regardless of how well they've been validated. Updating the standard formally authorizes passkeys as an approved implementation method, giving every downstream document (and every administrator) the authority to use them. That makes B correct. A is wrong because the access-control policy operates at a higher, technology-neutral level — it mandates MFA but intentionally delegates technology specifics to the standard. Rewriting the policy every time a new technology is approved would make it bloated and brittle; that's exactly why standards exist beneath it. C is wrong because procedures describe how to enroll in already-approved methods. Adding enrollment steps for passkeys before they're listed in the standard creates an unauthorized workaround — procedure documents don't grant approval authority. D is wrong because guidelines are optional recommendations, not mandatory controls. Something appearing in a guideline doesn't authorize it for compliance purposes. Your study tip: memorize the policy → standard → procedure → guideline hierarchy. On exam questions, ask yourself which layer grants authority versus which layer describes steps. Standards authorize; procedures implement.

Question 8

A policy requires servers to be securely hardened. To make compliance measurable, an engineering team proposes requiring conformance to the "current industry benchmark." Several benchmark versions and profiles exist, and some recommended settings conflict with business applications.

Which documentation approach best translates the policy into an enforceable internal requirement?

  1. Add "use an industry benchmark" to a guideline and let each administrator choose a version and profile
  2. Place every benchmark setting in the policy so any later technical change requires executive reapproval
  3. Create a standard naming approved versions and profiles, including controlled deviations and review requirements (correct answer)
  4. Create a procedure listing installation steps but omit the required benchmark version and compliance profile
Explanation: When you see a question about translating a high-level security policy into something enforceable, think about the classic policy hierarchy: policy → standard → procedure → guideline. Each layer serves a different purpose — policies state what must be achieved, standards define specific measurable requirements, procedures explain how to implement them, and guidelines offer optional recommendations. The question is really asking you to identify which document type fits the job. A standard is the right tool here because it locks down specific, measurable requirements — like named benchmark versions and approved profiles — without being so rigid that every minor technical update triggers executive-level reapproval. Option C describes exactly this: a standard that identifies approved benchmark versions and profiles, accommodates real-world conflicts through controlled deviations, and schedules periodic reviews. This makes compliance auditable and manageable simultaneously. Option A is wrong because pushing decisions entirely to individual administrators through a guideline removes consistency and makes compliance unmeasurable — exactly the problem the policy was trying to solve. Option B embeds technical details directly into the policy itself, which is a governance anti-pattern; when benchmark versions change (and they will), you'd need executive sign-off just to update a version number, creating dangerous delays. Option D describes a procedure, but one that omits the benchmark version and profile — the very specifics that make compliance verifiable — rendering it useless for enforcement. Study tip: On cybersecurity exams, watch for questions that test whether you know which document type solves a given governance problem. Standards fill the critical gap between broad policy intent and operational specifics — that middle layer is frequently tested.

Question 9

A mandatory encryption standard requires an approved algorithm for all stored customer data. A legacy billing system cannot support the algorithm until it is replaced in nine months. Immediately disabling the system would interrupt critical billing, but leaving its data unprotected creates a known risk.

Which action best preserves the role of the standard while addressing the temporary limitation?

  1. Rewrite the encryption standard to describe encryption as optional whenever a system has documented operational or technical constraints
  2. Publish a guideline recommending encryption for legacy systems, allowing each system owner to decide whether the mandatory standard still applies to their environment
  3. Modify the billing procedure to omit encryption steps until the replacement is complete, without updating any other governance or risk documentation
  4. Approve a time-limited exception with documented risk ownership, compensating controls, scheduled review dates, and a defined expiration or remediation condition (correct answer)
Explanation: When you see a question about a system that can't yet comply with a mandatory security control, you're being tested on exception management — a core governance concept. The key question isn't "how do we avoid the standard?" but rather "how do we honor the standard's intent while acknowledging a temporary, documented gap?" A well-designed exception process does exactly that. It keeps the mandatory standard intact, assigns accountability to a named risk owner, requires compensating controls (like enhanced monitoring or access restrictions) to reduce exposure in the meantime, and sets a hard deadline or trigger for resolution. That's precisely what D describes — a time-limited exception with documented risk ownership, compensating controls, scheduled reviews, and a defined expiration. The standard remains authoritative; the exception is a controlled, visible deviation, not a loophole. A is a governance failure disguised as flexibility. Rewriting the standard to make encryption optional whenever constraints exist permanently weakens the control baseline — any system owner can now claim a constraint and opt out indefinitely. B converts a mandatory control into an advisory one by delegating compliance decisions to individual system owners. This eliminates the standard's authority entirely without any formal review or risk documentation. C is perhaps the most dangerous: it quietly modifies operational procedure without updating governance or risk documentation. This creates an undocumented gap — leadership and auditors have no visibility into the known risk, which is a transparency failure on top of a security gap. Your study tip: on governance questions, watch for answers that quietly eliminate the rule versus answers that formally manage deviation from the rule. The exception process is always preferable to erasing the standard.

Question 10

A business-continuity policy requires systems to be recoverable within approved business tolerances. A supporting standard requires daily backups for Tier 1 systems. An outdated operations procedure instructs administrators to run backups weekly. An audit finds that a Tier 1 system has been backed up weekly because administrators followed the procedure.

Which response most accurately addresses the document hierarchy and the compliance issue?

  1. Treat the daily requirement as controlling, correct the backup frequency, and revise the procedure to match the standard (correct answer)
  2. Treat the weekly procedure as controlling because operational personnel are expected to follow approved step-by-step instructions
  3. Treat both frequencies as acceptable because the policy establishes recoverability without specifying a backup schedule
  4. Revise the standard to weekly because a documented procedure is evidence that management accepted the lower frequency
Explanation: Whenever you see a question about governance documents, think in layers: policies sit at the top, standards translate policy into measurable requirements, and procedures provide step-by-step instructions to implement those standards. Higher-level documents always override lower-level ones when conflicts arise. In this scenario, the policy demands recoverability within business tolerances, the standard operationalizes that by requiring daily backups for Tier 1 systems, and the procedure — the lowest-tier document — incorrectly instructs weekly backups. The procedure contradicts the standard above it, which means it is simply wrong, not authoritative. The correct response is A: treat the daily standard as controlling, bring the backup frequency into compliance immediately, and fix the procedure so it accurately reflects what the standard requires. This closes both the technical gap and the documentation gap. Choice B gets the hierarchy exactly backwards. Procedures exist to implement standards, not override them. Operational personnel following a flawed procedure does not make that procedure correct — it makes it a compliance risk. Choice C misreads the policy's intent. The policy sets the goal (recoverability); the standard sets the mechanism (daily backups). You cannot ignore the standard by pointing only to the policy's general language — standards exist precisely to give the policy teeth. Choice D is a dangerous trap. The fact that a non-compliant procedure existed and was followed is evidence of a control failure, not management acceptance. Revising a higher-level standard downward to match a broken procedure inverts the entire governance model. Study tip: On governance questions, always ask "which document sits higher in the hierarchy?" — the higher document wins every time, and procedures must always align up to standards, never the reverse.