CISSP Domain: Domain 1 – Security and Risk Management

CISSP Objective: 1.3 Evaluate and apply security governance principles

Focus: Security Policy, Security Program Management & Organizational Governance

Summary

CISSP Security Policy & Program Management covers how organizations translate governance and business objectives into security strategy, policies, standards, baselines, procedures, controls, metrics, and continuous improvement. This Domain 1 pillar guide explains policy architecture, program governance, roles and accountability, security awareness, exception management, measurement, audits, and the managerial decision-making principles required for the CISSP exam.

Security policies turn organizational governance into actionable expectations. Security program management turns those expectations into a coordinated, measurable, and continuously improving security capability.

Within CISSP Domain 1: Security and Risk Management, candidates must understand how security policies, standards, procedures, guidelines, baselines, roles, resources, metrics, awareness, risk management, and governance work together to create an effective information security program.

For the CISSP exam, this topic requires a managerial perspective.

A CISSP is not simply expected to ask:

The better questions are:

This pillar explains the principles behind building and managing an enterprise information security program.

1. What Is an Information Security Program?

An information security program is the coordinated collection of governance structures, policies, processes, people, technologies, controls, and activities used to manage information security risk across an organization.

A mature security program should:

• Support organizational objectives

• Protect information and systems

• Manage risk

• Establish responsibilities

• Define security requirements

• Coordinate security activities

• Meet legal and contractual obligations

• Provide appropriate resources

• Measure effectiveness

• Support continuous improvement

A security program is broader than a collection of technical controls.

Firewalls, encryption, endpoint protection, identity systems, and monitoring technologies are components of security—but they do not independently constitute a security program.

2. Governance, Program Management, and Operations

CISSP candidates should understand the relationship among these three layers.

Governance

Governance establishes:

• Direction

• Authority

• Accountability

• Risk expectations

• Strategic objectives

• Oversight

Program Management

Program management translates governance direction into coordinated security initiatives, policies, processes, resources, and controls.

Security Operations

Operations execute day-to-day security activities.

A simplified hierarchy is:

Governance

↓

Security Strategy

↓

Security Program

↓

Policies & Standards

↓

Processes & Controls

↓

Security Operations

↓

Measurement & Improvement

CISSP Exam Principle

When a question concerns organizational direction, begin with governance and business requirements—not individual technologies.

3. Business Alignment

The information security program must support the organization's mission.

Security should align with:

• Business objectives

• Organizational strategy

• Risk appetite

• Legal requirements

• Regulatory obligations

• Contractual commitments

• Customer expectations

• Operational priorities

Security programs that operate independently from business strategy can become ineffective, excessively restrictive, or poorly funded.

The goal is not maximum security at any cost.

The goal is:

4. Security Strategy

A security strategy establishes the long-term direction of the information security program.

It should answer questions such as:

• What are the organization's most important assets?

• What risks threaten business objectives?

• What security capabilities are required?

• What regulatory obligations apply?

• What level of risk is acceptable?

• What investments should be prioritized?

• How will success be measured?

The strategy should derive from organizational objectives rather than being created solely from available security technologies.

5. Security Policy

A security policy is a high-level statement of management intent regarding information security.

Policies establish mandatory expectations.

A strong policy should:

• Support business objectives

• Reflect management commitment

• Define responsibilities

• Establish expected behavior

• Address relevant risk

• Be approved by appropriate authority

• Be communicated to affected personnel

• Be enforceable

• Be periodically reviewed

Policies should generally explain what is required and why, rather than providing every technical implementation detail.

6. Policy, Standard, Baseline, Procedure, and Guideline

This hierarchy is fundamental to CISSP preparation.

Policy

A mandatory high-level statement of organizational intent.

Example: Sensitive organizational information must be protected against unauthorized disclosure.

Standard

A mandatory specific requirement supporting policy.

Example: Administrative access must use multifactor authentication.

Baseline

A minimum required level of security or configuration.

Example: All corporate Windows servers must conform to an approved hardened configuration baseline.

Procedure

Detailed steps explaining how to perform a task.

Example: Steps for provisioning and disabling user accounts.

Guideline

Recommended practice that generally allows flexibility.

Example: Recommendations for secure remote-work environments.

A useful memory structure is:

Policy = What and why

Standard = Mandatory specifics

Baseline = Minimum acceptable level

Procedure = How

Guideline = Recommended approach

7. Why the Policy Hierarchy Matters

Organizations need consistency without forcing every security decision into a single document.

High-level policies should remain relatively stable.

Detailed technical requirements change more frequently.

For example:

A policy may require strong authentication.

A standard may require MFA for privileged accounts.

A baseline may define approved configuration settings.

A procedure may explain enrollment.

A guideline may recommend additional protections for high-risk travel.

This structure allows technical requirements to evolve without constantly rewriting executive-level policies.

8. Types of Security Policies

Organizations may use several policy structures.

Enterprise Information Security Policy

Provides high-level direction for the organization's overall security program.

Issue-Specific Security Policy

Addresses a particular subject.

Examples:

• Acceptable use

• Remote access

• Email

• Artificial intelligence

• Social media

• Mobile devices

System-Specific Security Policy

Defines security requirements for a particular system, platform, or technology.

Examples:

• Database security

• Firewall configuration

• Cloud platform requirements

• Application security

The terminology and structure may vary among organizations, but the underlying purpose remains consistent.

9. Acceptable Use Policy

An Acceptable Use Policy (AUP) defines appropriate and prohibited use of organizational systems and resources.

It may address:

• Internet use

• Email

• Software installation

• Personal use

• Data handling

• Social media

• Remote access

• Monitoring

• Prohibited activities

Users should understand their responsibilities before being granted access.

10. Policy Approval

Security policy must have appropriate organizational authority.

Policies should generally be approved by management at a level appropriate to their scope.

Why?

Because a security policy represents management's direction, not simply the preferences of the security department.

Without management support, enforcement can become inconsistent or ineffective.

CISSP Exam Thinking

When asked what provides authority to an enterprise security policy, look toward senior management approval and organizational governance.

11. Policy Communication

A policy cannot effectively govern behavior if relevant personnel do not know it exists.

Organizations should:

• Publish policies

• Communicate requirements

• Provide training where needed

• Obtain acknowledgment where appropriate

• Make policies accessible

• Explain responsibilities

Communication should be appropriate to the audience.

Technical administrators may need detailed standards.

Executives may need risk and accountability information.

General users need clear behavioral expectations.

12. Policy Enforcement

Policies should be enforceable and consistently applied.

Enforcement may involve:

• Technical controls

• Monitoring

• Management oversight

• Human resources processes

• Disciplinary mechanisms

• Audits

• Exception management

A policy that is routinely ignored can weaken security culture and organizational credibility.

13. Policy Exceptions

There will be circumstances where a policy requirement cannot be met.

Exceptions should not occur informally.

A mature exception process should include:

1. Documenting the requirement

2. Explaining the business justification

3. Assessing the risk

4. Identifying compensating controls

5. Obtaining approval from appropriate authority

6. Establishing an expiration or review date

7. Monitoring the exception

CISSP Principle

14. Security Baselines

Baselines establish minimum acceptable security configurations or protection levels.

Examples include:

• Operating system hardening

• Network device configuration

• Cloud security settings

• Endpoint configuration

• Database security

• Mobile device settings

Baselines promote consistency and reduce configuration drift.

They may be based on:

• Organizational requirements

• Vendor guidance

• Industry benchmarks

• Regulatory requirements

• Risk assessments

15. Configuration Management

Configuration management ensures systems remain in known, authorized, and appropriately secured states.

Important activities include:

• Establishing baselines

• Documenting configurations

• Controlling changes

• Detecting deviations

• Maintaining inventories

• Reviewing configurations

Configuration drift can gradually weaken security even when systems were originally deployed securely.

16. Change Management

Changes to systems can introduce risk.

A formal change-management process typically considers:

• Business justification

• Risk

• Security impact

• Testing

• Approval

• Scheduling

• Documentation

• Rollback planning

• Post-implementation review

Exam Principle

Urgency does not automatically justify uncontrolled changes.

Emergency change processes may be faster, but they should still maintain appropriate authorization and documentation.

17. Roles and Responsibilities

An effective security program requires clear ownership.

Roles may include:

Senior Management

Provides direction, resources, authority, and oversight.

CISO

Leads the information security program and aligns security with organizational objectives.

Security Managers

Coordinate security activities and capabilities.

Data Owners

Determine classification and protection requirements.

Data Custodians

Implement and maintain controls according to owner requirements.

System Owners

Maintain responsibility for systems and associated risk.

Users

Follow security policies and protect organizational resources.

Internal Audit

Provides independent assurance regarding controls and compliance.

Clear responsibilities reduce gaps and conflicting expectations.

18. Responsibility, Accountability, and Authority

These concepts should remain aligned.

Responsibility — obligation to perform an activity.

Accountability — answerability for results.

Authority — power to make decisions or direct actions.

A person should not be held accountable for an outcome without sufficient authority to perform the associated responsibility.

This alignment is an important governance principle.

19. RACI

Organizations may use a RACI matrix to clarify roles.

RACI commonly represents:

Responsible

Performs the work.

Accountable

Ultimately owns the outcome.

Consulted

Provides input.

Informed

Receives relevant information.

RACI can help eliminate ambiguity in complex security programs.

20. Resource Management

A security program requires appropriate resources.

Resources include:

• Personnel

• Budget

• Technology

• Training

• Time

• External services

Security leaders should prioritize resources according to risk and business value.

Not every security problem deserves equal funding.

A mature program directs resources toward the risks that matter most.

21. Security Budgeting

Security budgets should be connected to:

• Business objectives

• Risk

• Regulatory requirements

• Asset value

• Threat exposure

• Strategic priorities

Technical fear alone is a weak basis for investment.

A stronger business case explains:

Risk → Business impact → Required capability → Cost → Expected risk reduction

22. Security Awareness, Education, and Training

People are a critical part of the security program.

These three concepts have different purposes.

Awareness

Builds general recognition of security responsibilities and threats.

Training

Develops specific skills required to perform tasks securely.

Education

Develops deeper conceptual knowledge and professional capability.

A simple distinction is:

Awareness = Know

Training = Do

Education = Understand

23. Role-Based Security Training

Not everyone requires identical security training.

Specialized training may be appropriate for:

• Developers

• Administrators

• Executives

• Help desk personnel

• Finance staff

• HR

• Incident responders

• Privileged users

Role-based training increases relevance and effectiveness.

24. Security Culture

Security culture reflects the shared attitudes and behaviors surrounding security.

A strong security culture requires more than annual awareness training.

It is influenced by:

• Leadership behavior

• Accountability

• Communication

• Policy enforcement

• Incentives

• Reporting mechanisms

• User experience

• Management support

Employees should understand that security supports organizational success rather than viewing it solely as an IT restriction.

25. Security Metrics

Security programs need measurable indicators.

Metrics should help answer:

• Are controls effective?

• Is risk increasing?

• Are objectives being achieved?

• Where are resources needed?

• Are improvements working?

Useful metrics should be:

• Relevant

• Measurable

• Actionable

• Consistent

• Connected to business objectives

26. Key Performance Indicators

KPIs measure performance against objectives.

Examples may include:

• Patch compliance

• Mean remediation time

• Training completion

• Incident response performance

• Control implementation progress

KPIs help management understand whether security processes are performing as expected.

27. Key Risk Indicators

KRIs provide insight into risk exposure.

Examples might include:

• Number of critical unsupported systems

• Percentage of privileged accounts without required controls

• Increase in high-risk third-party findings

• Critical vulnerabilities beyond approved remediation periods

KPIs ask:

KRIs ask:

28. Metrics vs. Raw Data

More data does not necessarily create better management information.

Consider:

This number alone provides limited decision value.

A stronger executive metric might be:

The second statement connects technical information to:

• Risk

• Critical assets

• Time

• Business impact

CISSP Principle

Executives generally need decision-relevant risk information, not raw technical volume.

29. Security Reporting

Different audiences require different reporting.

Board and Executives

Need:

• Business risk

• Strategic trends

• Material exposures

• Regulatory concerns

• Investment requirements

Security Management

Needs:

• Program performance

• Risk trends

• Control effectiveness

• Operational priorities

Technical Teams

Need:

• Detailed findings

• Configuration issues

• Vulnerabilities

• Remediation actions

Good reporting translates security information into the language appropriate for the audience.

30. Security Program Maturity

Security programs evolve.

A less mature program may be:

• Reactive

• Inconsistent

• Poorly documented

• Dependent on individuals

• Difficult to measure

A more mature program tends to be:

• Defined

• Repeatable

• Risk-based

• Measured

• Governed

• Continuously improved

Maturity does not mean complexity for its own sake.

It means security activities are increasingly predictable, controlled, measurable, and aligned with organizational needs.

31. Continuous Improvement

Security programs cannot remain static.

Changes occur in:

• Threats

• Technology

• Business operations

• Regulations

• Personnel

• Vendors

• Cloud environments

• Artificial intelligence

• Organizational priorities

Programs should therefore continually:

Assess → Plan → Implement → Measure → Improve

Lessons from incidents, audits, assessments, exercises, and metrics should feed back into the program.

32. Risk Management Integration

Security program management should be risk-based.

Risk management helps determine:

• Which initiatives receive priority

• Which controls are justified

• Which risks require escalation

• Which exceptions may be acceptable

• Where resources should be invested

Security programs disconnected from enterprise risk management can overprotect low-value assets while leaving critical business risks insufficiently addressed.

33. Risk Register

A risk register provides structured documentation of identified risks.

It may contain:

• Risk description

• Affected assets

• Likelihood

• Impact

• Risk rating

• Risk owner

• Treatment strategy

• Controls

• Residual risk

• Status

• Review dates

The risk register supports accountability and ongoing monitoring.

34. Issue Management vs. Risk Management

A risk concerns uncertainty that may affect objectives.

An issue is generally a problem or condition that already exists and requires action.

For example:

Risk: A critical server may fail because redundancy is insufficient.

Issue: The critical server has failed.

Understanding this distinction improves program reporting and prioritization.

35. Security Projects vs. Security Programs

A project has a defined objective and usually a defined beginning and end.

Examples:

• Deploy MFA

• Replace a firewall

• Implement DLP

A program coordinates multiple related activities to achieve broader strategic objectives.

Examples:

• Identity security program

• Vulnerability management program

• Data protection program

• Security awareness program

Program management therefore operates at a broader level than individual project execution.

36. Security Program Charter

A program charter can formally establish the security program's:

• Purpose

• Scope

• Authority

• Objectives

• Responsibilities

• Governance structure

• Reporting relationships

Executive sponsorship gives the program organizational authority.

37. Security Steering Committee

Organizations may establish a security steering committee to provide cross-functional governance and coordination.

Participants may represent:

• Executive management

• Security

• IT

• Legal

• Privacy

• Compliance

• Risk

• Finance

• HR

• Business units

A steering committee helps ensure security decisions reflect organizational priorities rather than only technical concerns.

38. Security Architecture and Program Management

Security architecture should support policies and program objectives.

Architecture translates requirements into structured security capabilities.

For example:

Policy: Sensitive information must be protected.

↓

Standard: Sensitive information must use approved encryption.

↓

Architecture: Centralized key management and approved encryption services.

↓

Implementation: Specific platforms and configurations.

Technology should therefore follow organizational requirements—not define them.

39. Vendor and Third-Party Management

Third parties can introduce substantial risk.

Security programs should address third-party relationships throughout their lifecycle.

Before Engagement

• Due diligence

• Risk assessment

• Security requirements

• Contract review

During the Relationship

• Monitoring

• Assessments

• Performance measurement

• Incident reporting

• Compliance verification

At Termination

• Access removal

• Data return

• Data destruction

• Account termination

• Asset recovery

Third-party risk management should be integrated into the overall security program.

40. Supply Chain Program Management

Organizations increasingly depend on complex technology supply chains.

Security considerations may include:

• Software providers

• Hardware suppliers

• Cloud services

• Managed services

• Open-source components

• Contractors

• Subcontractors

Security programs should identify critical dependencies and establish appropriate controls throughout the supply chain.

41. Cloud Security Program Management

Cloud environments require policies and governance just as traditional infrastructure does.

A cloud security program may address:

• Cloud usage

• Data classification

• Identity

• Encryption

• Configuration

• Logging

• Third-party risk

• Shared responsibility

• Incident response

• Compliance

Cloud adoption should occur within the organization's governance framework rather than becoming an uncontrolled parallel environment.

42. AI Security Policy and Program Management

Artificial intelligence creates an increasingly important security program responsibility.

Organizations may need policies addressing:

• Approved AI services

• Sensitive information in prompts

• Training data

• Intellectual property

• Model access

• AI-generated content

• Third-party AI platforms

• Human oversight

• Security testing

• Privacy

• Regulatory requirements

AI policy should align with existing:

• Information classification

• Privacy

• Acceptable use

• Vendor management

• Access control

• Incident response

CISSP Principle

New technology may require new controls, but it should remain governed by established principles of risk, accountability, policy, and oversight.

43. Exception Management

Modern organizations cannot always implement every security requirement exactly as intended.

A formal exception process prevents temporary deviations from becoming permanent undocumented weaknesses.

Every significant exception should answer:

• What requirement cannot be met?

• Why?

• What risk results?

• Who owns the risk?

• What compensating controls exist?

• Who approved the exception?

• When does the exception expire?

• When will it be reviewed?

An exception without an owner or expiration date can become unmanaged risk.

44. Documentation

Documentation supports:

• Consistency

• Accountability

• Auditability

• Training

• Knowledge transfer

• Incident response

• Compliance

• Legal defensibility

However, documentation should be maintained.

Outdated documentation can create false confidence and operational risk.

45. Record Retention

Security program records may be subject to retention requirements.

Examples include:

• Audit logs

• Incident records

• Risk assessments

• Policy acknowledgments

• Access records

• Training records

• Vendor assessments

Retention should reflect:

• Legal requirements

• Regulatory obligations

• Contracts

• Business needs

• Privacy requirements

46. Audit and Assurance

Audits provide independent evaluation of controls, processes, or compliance.

Auditors should maintain appropriate independence.

Security management may implement controls.

Audit evaluates whether those controls are designed and operating as expected.

CISSP Exam Principle

The person responsible for implementing a control should generally not be the only person independently evaluating its effectiveness.

47. Internal vs. External Audit

Internal Audit

Operates within the organization but should maintain independence from the activities being audited.

External Audit

Performed by independent external parties.

Each can provide different forms of assurance.

Audit findings should feed into remediation and program improvement.

48. Security Assessments

Security programs may use:

• Risk assessments

• Vulnerability assessments

• Penetration testing

• Configuration assessments

• Compliance assessments

• Control testing

• Maturity assessments

These activities answer different questions.

A vulnerability assessment does not replace a risk assessment.

A penetration test does not replace an audit.

The program should select assessment methods based on the objective.

49. Corrective Action Plans

When deficiencies are identified, organizations should track corrective actions.

A corrective action plan may include:

• Finding

• Root cause

• Risk

• Required remediation

• Owner

• Target date

• Status

• Validation

Simply identifying weaknesses does not improve security.

Findings must be managed through resolution or formal risk acceptance.

50. Management Review

Senior management should periodically review the security program.

Reviews may consider:

• Risk posture

• Significant incidents

• Compliance

• Audit findings

• Metrics

• Strategic initiatives

• Resource requirements

• Emerging threats

• Third-party risk

This creates a feedback loop between security operations and governance.

51. Security Program Lifecycle

A useful program lifecycle is:

1. Understand the Organization

Identify objectives, assets, stakeholders, obligations, and risk.

2. Establish Governance

Define authority, accountability, ownership, and oversight.

3. Develop Strategy

Determine security objectives and priorities.

4. Establish Policies

Translate strategic direction into requirements.

5. Implement Controls

Deploy administrative, technical, and physical safeguards.

6. Operate

Perform ongoing security activities.

7. Measure

Evaluate performance and risk.

8. Improve

Correct deficiencies and adapt to change.

Then repeat.

52. Common CISSP Policy & Program Management Traps

Trap: Security creates enterprise policy without management authority

Policies require appropriate management approval.

Trap: A procedure and policy are interchangeable

They are not. Policy establishes requirements; procedures describe how tasks are performed.

Trap: Guidelines are mandatory

Generally, guidelines provide recommended practices rather than mandatory requirements.

Trap: Exceptions can be granted informally

Exceptions should be risk-assessed, documented, authorized, monitored, and time-bound.

Trap: More metrics mean better governance

Metrics are useful only when they support decisions.

Trap: Technical teams should determine risk appetite

Risk appetite is established through organizational governance and leadership.

Trap: Security awareness is the same as training

Awareness builds recognition; training develops specific skills.

Trap: Passing an audit proves the organization is secure

An audit provides assurance regarding defined objectives and scope. It does not prove the absence of security risk.

Trap: Outsourcing transfers security accountability

Organizations retain important risk and governance responsibilities.

53. High-Yield CISSP Policy & Program Management Concepts

Candidates should understand:

• Security governance

• Security strategy

• Information security programs

• Business alignment

• Enterprise security policy

• Issue-specific policy

• System-specific policy

• Standards

• Baselines

• Procedures

• Guidelines

• Acceptable use policy

• Policy approval

• Policy enforcement

• Policy exceptions

• Configuration management

• Change management

• Roles and responsibilities

• RACI

• Security budgeting

• Awareness

• Training

• Education

• Security culture

• KPIs

• KRIs

• Security metrics

• Executive reporting

• Program maturity

• Continuous improvement

• Risk registers

• Security program charters

• Steering committees

• Third-party management

• Supply chain management

• Exception management

• Audit

• Corrective actions

• Management review

54. Policy & Program Management Topic Cluster

This pillar should serve as the central hub for deeper GoCyberNinja pages.

Policy Architecture

• Security Policies, Standards, Procedures, Guidelines & Baselines

• Enterprise Security Policy

• Acceptable Use Policy

• Security Baselines

• Policy Exceptions

• Policy Lifecycle

Security Program

• Information Security Program

• Security Strategy

• Security Governance

• Security Program Charter

• Security Steering Committee

• Security Program Maturity

• Continuous Improvement

Roles & Accountability

• Security Roles and Responsibilities

• Data Owner vs. Data Custodian

• Responsibility vs. Accountability

• RACI Matrix

• Separation of Duties

People & Culture

• Security Awareness

• Security Training

• Security Education

• Security Culture

• Role-Based Security Training

Measurement

• Security Metrics

• KPI vs. KRI

• Security Reporting

• Executive Security Reporting

• Security Program Effectiveness

Operational Governance

• Configuration Management

• Change Management

• Exception Management

• Corrective Action Plans

Third-Party & Emerging Technology

• Third-Party Risk Management

• Supply Chain Risk Management

• Cloud Governance

• AI Security Governance

• AI Acceptable Use Policy

55. Quick CISSP Knowledge Check

1. Who should provide authority for an enterprise information security policy?

Answer: Appropriate senior management.

2. Which document establishes mandatory high-level management expectations?

Answer: Policy.

3. Which document defines specific mandatory requirements supporting a policy?

Answer: Standard.

4. Which document provides detailed instructions for performing a task?

Answer: Procedure.

5. A system cannot comply with an established security standard. What should happen?

Answer: Use the formal exception process, assess the resulting risk, implement appropriate compensating controls, obtain authorized approval, and establish review or expiration requirements.

6. What is the difference between a KPI and a KRI?

Answer: A KPI measures performance toward an objective; a KRI provides insight into changing risk exposure.

7. Who should accept significant residual business risk?

Answer: The appropriately authorized business or risk owner—not simply the security administrator.

8. Why should security metrics be connected to business objectives?

Answer: Because security leadership and executives need information that supports risk and resource decisions rather than raw technical statistics.

56. Exam Thinking: The Policy & Program Decision Chain

For difficult CISSP program-management questions, think in this order:

Business Mission

↓

Business Objectives

↓

Governance & Risk Appetite

↓

Security Strategy

↓

Security Policy

↓

Standards & Baselines

↓

Procedures

↓

Controls & Operations

↓

Metrics

↓

Management Review

↓

Continuous Improvement

When the exam offers both a technical solution and an organizational solution, determine where in this chain the problem actually exists.

Do not fix a governance problem with a firewall.

Do not fix a policy problem with an undocumented technical workaround.

Do not fix a technical problem by rewriting enterprise strategy unnecessarily.

Choose the action appropriate to the level of the problem.

Final Takeaway

Security policy and program management connect executive governance with day-to-day security operations.

Governance establishes direction.

Strategy determines priorities.

Policy establishes management expectations.

Standards and baselines define mandatory requirements.

Procedures explain how work is performed.

Controls implement protection.

Metrics reveal performance and risk.

Management review drives improvement.

Together they create a repeatable cycle:

For CISSP candidates, the most important lesson is that security is not simply a collection of technologies.

An effective security program is a business-aligned, risk-based management system supported by policies, clearly defined responsibilities, appropriate controls, meaningful measurement, executive oversight, and continuous improvement.

When answering CISSP questions, identify the organizational level of the problem before selecting the solution. That distinction frequently separates a technically reasonable answer from the best CISSP answer.

Related CISSP Topics

Continue your Domain 1 study with: