What are organization-defined parameters (ODPs) in ITSP.10.171 and how do I set them?

Answer

ODPs are placeholders in ITSP.10.171 allowing organizations to specify security control values tailored to their context, risk profile, and capabilities.

What Are Organization Defined Parameters

ODPs are placeholders within ITSP.10.171 security requirements where organizations must specify particular values appropriate to their situations. They appear as square brackets in requirement text indicating assignment or selection operations.

Assignment operations require organizations to specify values like timeframes, frequencies, personnel, or thresholds. For example, "limit consecutive invalid logon attempts to [organization-defined number]."

Selection operations require organizations to choose from defined options or specify criteria. For example, "notify [organizational personnel or roles]."

ODPs allow requirements to be adapted to different organizational sizes, missions, risk profiles, and operational contexts without diluting security.

Without ODPs, requirements would either be too prescriptive (mandating approaches unsuitable for some contexts) or too vague (providing insufficient guidance).

ODPs balance standardization with flexibility—core requirement is standardized while implementation details are tailorable.

Why ODPs Exist

ITSP.10.171 applies to diverse organizations from small contractors to large aerospace firms, from IT service providers to manufacturers. Different organizations have vastly different capabilities, risks, and operational contexts.

Rigid requirements appropriate for large enterprise might be impractical for small business, while requirements too lenient for high-risk environments would inadequately protect specified information.

ODPs enable risk-based tailoring where higher-risk systems or more capable organizations implement more stringent parameters while lower-risk systems or resource-constrained organizations use less aggressive parameters within reasonable bounds.

They accommodate technology diversity by allowing different values for different technologies rather than one-size-fits-all mandates.

ODPs support continuous improvement by allowing organizations to tighten parameters as security maturity increases.

They reflect reality that some security decisions require judgment based on specific circumstances rather than arbitrary universal values.

Common ODP Examples

ITSP.10.171 includes ODPs throughout its requirements. The following categories illustrate common ODP types.

• Timeframes like "within [organization-defined time period]" appear in requirements for incident notification, account lockout duration, audit record retention, and session termination
• Personnel and roles like "[organization-defined personnel or roles]" require identifying who will perform security functions, receive alerts, or make decisions
• Frequencies like "at [organization-defined frequency]" appear in requirements for security assessments, policy reviews, training, and vulnerability scanning
• Thresholds like "[organization-defined number]" apply to failed logon attempts, password length, or other measurable limits
• Lists like "[organization-defined events]" require specifying what events to log, what security services to use, or what information types exist
• Criteria like "[organization-defined circumstances]" require defining conditions triggering specific actions

Organizations must define appropriate periods based on risk, operational needs, and capabilities. Each ODP requires thoughtful organizational decision balancing security effectiveness, operational practicality, and available resources.

Factors Influencing ODP Selection

Multiple considerations inform ODP value determination. Organizations should evaluate the following factors when selecting ODP values.

• Risk assessment is primary factor—higher sensitivity information or higher threat exposure warrants more aggressive parameters
• Regulatory and contractual requirements may specify certain values or constrain choices
• Operational impact since overly restrictive parameters may disrupt legitimate work or create unacceptable user friction
• Technical capability constraints where aggressive parameters may exceed system capabilities or require technology investments
• Industry best practices provide guidance on reasonable parameter ranges for various requirements
• Benchmarking peer organizations in similar industries or with similar risk profiles offers perspective
• Resource availability including staffing, budget, and technical expertise affects what parameters are sustainable
• Business requirements including operational hours, global operations, or customer access needs influence appropriate parameters

Organizations should document analysis supporting ODP selections rather than arbitrary choices.

Process for Defining ODPs

A systematic approach ensures appropriate ODP values through the following phases.

• Identification phase catalogs all ODPs across ITSP.10.171 requirements applicable to organization's scope—approximately 100-150 ODPs exist throughout standard
• Analysis for each ODP examines requirement purpose, risk mitigation objective, implementation options, and tradeoffs between security and operations
• Stakeholder input engages security personnel, IT operations, business units, and management in ODP discussions—different perspectives identify considerations that technical security teams might miss
• Draft proposals suggest specific ODP values with supporting rationale explaining why proposed values are appropriate
• Impact assessment evaluates how proposed ODPs affect operations, user experience, resource requirements, and security posture
• Management review and approval by appropriate authority (CISO, executive management, or security steering committee) ensures ODPs have organizational acceptance
• Documentation records all ODP values, rationale, and approvals in system security plans or security documentation

Organizations should complete ODP definition early in CPCSC implementation—ODP values drive subsequent technical implementation and procedural development.

Documenting ODPs

Clear documentation of ODPs is essential for compliance demonstration. Effective documentation includes multiple components.

• Centralized ODP listing compiles all ODPs, selected values, rationale, and approvals in single reference document or section of system security plan
• In-line documentation within policies and procedures replaces bracketed placeholders with actual defined values—for example, policy states "reset passwords annually" rather than generic "at [organization-defined frequency]"
• Rationale statements explain why particular values were selected, addressing risk analysis, operational considerations, and capability constraints
• Approval records show management acceptance of ODP values
• Cross-references link each ODP to relevant policies, procedures, and technical implementations

During CPCSC Level 2 assessments, assessors will examine ODP documentation to verify organizations have thoughtfully defined values rather than arbitrary or absent parameters.

Well-documented ODPs demonstrate security program maturity and reasonable decision-making.

ODP Flexibility vs Baseline Requirements

ODPs provide flexibility within boundaries, not unlimited discretion. Several constraints apply to ODP selection.

• Reasonable ranges exist for most ODPs—for example, incident notification "within 72 hours" is reasonable while "within 6 months" would not be
• Some ODPs have practical minimum thresholds driven by security effectiveness—for example, password length below 8 characters or failed logon threshold above 10 attempts would be questionable
• Industry standards and best practices constrain reasonable ODP ranges
• During assessments, assessors evaluate whether ODP selections are reasonable given organizational context—significantly outlier values require strong justification

Organizations should avoid defining ODPs to minimize security burden rather than meeting security needs. The goal is implementing effective security tailored to context, not gaming requirements through permissive ODPs.

Assessors may challenge ODP selections they consider inadequate for protecting specified information.

Examples of Appropriate ODP Selection

Practical examples illustrate good ODP definition across common requirement areas.

• Incident notification timeframe might be defined as "within 24 hours" for incidents affecting specified information, reflecting urgency of government notification obligations
• Failed logon attempts threshold might be "5 consecutive invalid attempts" balancing security (limiting brute force attacks) against user experience (not locking out legitimate users making occasional typos)
• Audit log retention might be "90 days in online SIEM storage with additional 2 years in archival storage" meeting investigation needs and compliance requirements
• Security assessment frequency might be "annually for comprehensive assessment with continuous automated vulnerability scanning" providing regular evaluation within resource constraints
• Password change frequency might be "annually or when compromise is suspected" recognizing that mandatory frequent changes may reduce security
• Training frequency might be "annual refresher training for all personnel with immediate training for new hires and role-specific training when job duties change" ensuring current awareness

These examples show ODP selections driven by risk, practicality, and capabilities rather than arbitrary choices.

Reviewing and Updating ODPs

ODPs aren't permanent once defined—they should evolve with organizational circumstances. Organizations should conduct regular reviews to ensure ongoing appropriateness.

• Annual review evaluates whether current ODP values remain appropriate or should be adjusted based on experience
• Trigger-based review occurs after security incidents revealing inadequate parameters, organizational changes affecting risk or capabilities, technology changes enabling different parameters, or assessment findings suggesting ODP modifications
• Maturity progression tightens ODPs as organizational security maturity increases and resources grow—organizations might start with more permissive parameters and progressively strengthen them
• Loosening parameters might occur if initially aggressive values prove operationally unsustainable, though this requires careful security analysis

ODP changes should follow formal change control with analysis, approval, and documentation similar to initial ODP definition.

Organizations should track ODP evolution over time showing continuous security improvement.

Common ODP Pitfalls

Organizations should avoid common mistakes in ODP selection. The following pitfalls frequently undermine effective ODP implementation.

• Undefined ODPs where implementation proceeds without actually defining values, leaving bracketed placeholders in documentation or inconsistent implementations across systems
• Arbitrary values selected without analysis or rationale
• Overly permissive selections minimizing security burden rather than meeting security needs
• Inconsistent values where similar ODPs have vastly different values without justification
• Copy-paste selections importing ODPs from other organizations without considering own context
• Neglecting documentation by defining values in practice but not formally documenting them
• Ignoring operational impact by defining theoretically ideal values that prove impractical

Organizations should approach ODPs systematically and deliberately, recognizing they're opportunities for thoughtful tailoring that improve both security effectiveness and operational sustainability.

ODP Considerations for Different Organization Sizes

Organization size significantly influences appropriate ODP values. Different organizational scales face different constraints and capabilities.

Small organizations might define ODPs conservatively given limited capabilities—for example, longer response timeframes recognizing limited after-hours coverage, less frequent assessments given resource constraints, or reliance on automated tools over manual processes.

However, small organizations must still meet baseline security—ODPs can't eliminate requirements entirely.

Large organizations might define more aggressive ODPs leveraging greater resources—for example, rapid response timeframes given 24/7 security operations, frequent assessments given dedicated security teams, or extensive logging given sophisticated SIEM infrastructure.

Medium organizations typically fall between these extremes.

During assessments, assessors evaluate ODP appropriateness in context of organizational size and capabilities—what's reasonable varies.

Organizations should define ODPs appropriate to their actual circumstances rather than aspirational ideal or minimal acceptable values.

Learn More

The following resources provide additional guidance on ODPs and ITSP.10.171 compliance.

• Protecting Specified Information (ITSP.10.171)
• Security and Privacy Controls Catalogue (ITSP.10.033)