System Planning Policy and Procedures

Version: 1.1 approved
Download PDF Controlled copy — valid on date of download only

Internal Use

System Planning Policy and Procedures

Dispel

Document Control

ItemDetails
Version1.0
CadenceAnnual
Policy OwnerChief Technology Officer
Approved ByChief Executive Officer
DCF ReferencesDCF-1, DCF-13, DCF-15, DCF-16, DCF-17, DCF-21, DCF-22, DCF-25, DCF-32, DCF-35, DCF-36, DCF-38, DCF-39, DCF-40, DCF-41, DCF-43, DCF-44, DCF-45, DCF-47, DCF-48, DCF-49, DCF-53, DCF-54, DCF-55, DCF-56, DCF-57, DCF-58, DCF-60, DCF-68, DCF-96, DCF-99, DCF-100, DCF-134

1. PURPOSE AND SCOPE

1.1 Purpose

The purpose of this policy and procedures document is to define how Dispel plans systems and supporting architectures, including the Dispel Zero Trust Engine, so that security, privacy, and business objectives are integrated from the outset.

1.2 Scope

This policy applies to:

  • Planning activities for new systems and significant changes to existing systems.
  • Development and maintenance of system security and privacy plans and related documentation.
  • All Covered Persons involved in system planning, design, and governance.

1.3 Regulatory and Framework Alignment

#Framework / StandardRelevant Control IDsAlignment Notes
1SOC 2CC1.2, CC3.2Governance and risk processes that inform system planning.
2ISO/IEC 270016.1, 6.2Actions to address risks and information security objectives in planning.
3NIST SP 800-53PL-1, PL-2, PL-4, PL-10, PL-11Planning policy and procedures, system security and privacy plans, rules of behavior, and control baseline selection and tailoring.
4IEC 6244362443-2-1Cybersecurity program requirements and planning for industrial environments.
5HIPAA164.308(a)(1)Risk management and planning for systems handling ePHI.

2. POLICY STATEMENTS

2.1 Management Commitment

Management Commitment Statement

Senior Management at Dispel is dedicated to the protection of our information assets, industrial control systems, and Protected Health Information (PHI). We assume full accountability for the effectiveness of our security program, ensuring it is integrated into all business processes and aligned with our strategic goals. To maintain compliance with ISO 27001, IEC 62443, HIPAA, and NIST 800-53, we formally commit to:

  • Resource Provisioning: Providing the necessary financial, technical, and human resources to sustain a robust security posture.
  • Risk-Based Governance: Approving security policies and overseeing a continuous risk management process that prioritizes both data privacy and operational safety.
  • Operational Resilience: Supporting the security of industrial automation and control systems (IACS) to ensure safety and reliability.
  • Continuous Oversight: Conducting regular management reviews to evaluate program performance, audit results, and opportunities for improvement.

2.2 Primary Policy Statement

Dispel SHALL ensure that system planning activities produce documented plans and architectures that reflect security and privacy requirements and align with organizational objectives.

2.3 Secondary Policy Statement

  • System security and privacy plans SHALL be prepared, approved, and maintained for in-scope systems.
  • Planning activities SHALL identify and document control baselines and tailoring decisions.

3. REQUIREMENTS

3.1 Planning Governance and Review Tempo

Objective: Establish governance for system planning.

Mandatory Activities:

  1. The Policy Owner SHALL own this policy and associated procedures and ensure they are reviewed at least annually.
  2. System planning roles and responsibilities SHALL be defined and documented.
  3. This policy and procedures SHALL be disseminated to Covered Persons involved in planning; review, acceptance, and acknowledgement SHALL be required initially and at least annually.

Required Outputs:

  • Approved planning policy and procedures.
  • Records of acknowledgements for relevant roles.

Security Controls: NIST SP 800-53 PL-1.


3.2 System Security and Privacy Plans

Objective: Ensure systems have current security and privacy plans.

Mandatory Activities:

  1. For in-scope systems, Dispel SHALL develop and maintain system security and privacy plans that:
    • Describe system purpose, context, and architecture.
    • Identify information types and categorization.
    • Document applicable control baselines and overlays, and tailoring decisions.
    • Describe implemented and planned controls.
  2. Plans SHALL be reviewed and approved by appropriate officials prior to implementation and updated when significant changes occur or at least annually.

Required Outputs:

  • System security and privacy plans.
  • Records of plan reviews and approvals.

Security Controls: NIST SP 800-53 PL-2.


3.3 Rules of Behavior and Architecture Planning

Objective: Define rules of behavior and document system architecture.

Mandatory Activities:

  1. Rules of behavior for users and administrators SHALL be defined and documented for in-scope systems.
  2. System security and privacy architectures SHALL be documented, including dependencies and external interfaces.
  3. Architectures and rules of behavior SHALL be reviewed periodically and updated as needed.

Required Outputs:

  • Rules of behavior documentation.
  • Architecture diagrams and descriptions.

Security Controls: NIST SP 800-53 PL-4, PL-8.


3.4 Control Baseline Selection and Tailoring

Objective: Select and tailor control baselines.

Mandatory Activities:

  1. Dispel SHALL select relevant control baselines and overlays for systems, based on categorization and applicable requirements.
  2. Tailoring decisions (e.g., control enhancements, compensating controls, exclusions) SHALL be documented and justified.
  3. Control baselines and tailoring SHALL be reviewed periodically and updated as needed.

Required Outputs:

  • Control baseline selection and tailoring documentation.

Security Controls: NIST SP 800-53 PL-10, PL-11.


4. ROLES AND RESPONSIBILITIES

4.1 Policy Owner

Responsibilities:

  • Owns this System Planning Policy and Procedures.
  • Ensures alignment with risk assessment, configuration management, and SDLC policies.
  • Coordinates periodic reviews and updates.

4.2 Security Officer / Architecture Leads

Responsibilities:

  • Lead development of system security and privacy plans.
  • Define and maintain security architectures for in-scope systems.
  • Support control baseline selection and tailoring.

4.3 System Owners

Responsibilities:

  • Provide system context, requirements, and constraints for planning.
  • Review and approve system plans and architectures.
  • Ensure planned controls are implemented for their systems.

5. PROCEDURES

5.1 System Planning Lifecycle (High-Level)

StepActionResponsible PartyTimeframe
1Define system purpose, scope, and context.System Owners, Security OfficerDuring initial planning
2Develop or update system security and privacy plans and architectures.Security Officer, Architecture LeadsBefore major design/implementation
3Select and tailor control baselines; document decisions.Security Officer, Policy OwnerDuring planning
4Obtain approvals and communicate plans to relevant stakeholders.System Owners, Policy OwnerBefore implementation
5Review and update plans and baselines as systems or risks change.Policy Owner, System OwnersAt least annually or upon significant change

6. MONITORING AND COMPLIANCE

6.1 Compliance Monitoring

Compliance with this policy SHALL be monitored through:

  • Reviews of system plans and architectures.
  • Audits of control baseline selection and tailoring documentation.
  • Verification that planned controls are reflected in implementation.

6.2 Metrics and Reporting

The following metrics SHALL be tracked and reported at least annually to the Policy Owner and senior management:

MetricFrequencyOwner
Percentage of in-scope systems with current security and privacy plansAnnualPolicy Owner
Number of significant changes without corresponding plan updatesAnnualSecurity Officer

6.3 Non-Compliance Consequences

Failure to comply with this policy and procedures may result in:

  • Misalignment between system implementations and organizational risk posture.
  • Revocation or restriction of access for Covered Persons who repeatedly fail to follow planning procedures.
  • Disciplinary action for employees and contractors, consistent with Dispel HR policies and applicable law.

7. EXCEPTIONS AND WAIVERS

7.1 Exception Process

Exceptions to this policy SHALL:

  1. Be submitted in writing by the requesting party.
  2. Identify the specific policy or procedural requirements for which an exception is sought.
  3. Include justification and business impact.
  4. Describe compensating controls or mitigation measures.
  5. Define exception duration and remediation plan.

7.2 Exception Approval Authority

Risk LevelApproval Authority
LowPolicy Owner
MediumPolicy Owner and Security Officer
HighPolicy Owner, Security Officer, and Senior Management representative
CriticalSenior Management representative in consultation with Policy Owner and Security Officer

8. DEFINITIONS

System Security Plan (SSP): A document that provides an overview of the security requirements for a system and describes the controls in place or planned to meet those requirements.

Control Baseline: A set of security and privacy controls selected for a system based on its categorization and risk environment.


9. REFERENCES

9.1 Internal References

  • Risk Assessment Policy and Procedures.
  • System Development Lifecycle documents.
  • Information Security Policy.

9.2 External References

  • NIST SP 800-53, PL family.
  • NIST SP 800-37 and SP 800-30.
  • ISO/IEC 27001 and ISO/IEC 27005.

10. DOCUMENT HISTORY

VersionDateAuthorChanges
1.1Predates version controlEthan SchmertzlerAligned System Planning Policy and Procedures to POLICY_TEMPLATE and updated control mappings.
1.0Predates version controlEthan SchmertzlerInitial System Planning Policy and Procedures.

11. APPROVAL SIGNATURES

RoleNameSignatureDate
Policy Owner
Security Officer
Senior Management Representative

APPENDICES

Appendix A: Supporting System Planning Procedures

This appendix may include:

  • Templates for system security and privacy plans.
  • Sample architecture diagrams and documentation formats.

Appendix B: Additional Guidance and Examples

This appendix may include:

  • Example planning scenarios and lessons learned.
  • References to industry best practices for system planning.

Document Provenance

Last ModifiedApril 6, 2026 at 12:37 -0400
Authorunknown
Signature Not signed
Commit547bdca View on GitHub
File HistoryAll changes