Acceptable Use, Business Continuity, and Disaster Recovery Policies
Security policies are the foundational documents that define what an organization requires regarding security. Policies state what must be done and why. Technical controls implement how the policy requirements are met. Without policies, technical controls lack authority and enforceability.
Information Security Policy
The information security policy (sometimes called the master security policy) is the top-level document that establishes the organization's commitment to security. It defines: the scope of security requirements across the organization; roles and responsibilities for security; management's commitment and support; consequences for non-compliance. All other security policies derive their authority from the information security policy. This policy is owned by senior management and approved at the executive or board level.
Acceptable Use Policy (AUP)
An acceptable use policy (AUP) defines what employees and other users are permitted to do with organizational information systems, networks, and data. The AUP covers:
- Permitted uses: Business-related activities authorized on organizational systems
- Prohibited uses: Activities that are specifically forbidden (personal use that exceeds limits, illegal activities, sharing confidential data without authorization, installing unauthorized software)
- Monitoring disclosure: Notice that organizational systems may be monitored and that users have no expectation of privacy on those systems
- Consequences: What happens if the AUP is violated (disciplinary action, termination, legal action)
Legal liability limitation: The AUP is a critical legal document. By establishing clear rules and requiring employee acknowledgment (signature), the organization limits its legal liability when violations occur. If an employee commits an illegal act using organizational systems and the organization had no AUP, the organization may bear greater liability for enabling the conduct. An acknowledged AUP creates a documented notice that the conduct was prohibited.
Business Continuity Planning (BCP)
Business continuity planning addresses how the organization will maintain critical business functions when normal operations are disrupted. BCP is broader than disaster recovery — it focuses on keeping the business running during a disruption, not just recovering IT systems after one.
- Manual alternatives: BCP must document how business processes can continue without technology. If an order processing system is down, can orders be taken by phone and recorded on paper? If payroll software fails, how are employees paid? BCP documents these manual fallback procedures.
- Testing requirement: A BCP that has never been tested is not a viable plan — it is a document that may contain errors, outdated procedures, and untested assumptions. BCP must be tested regularly (tabletop exercises, simulations) to verify that manual procedures actually work and that responsible personnel know what to do.
- BIA (Business Impact Analysis): Identifies which business functions are most critical, how long each function can be suspended before unacceptable harm results (RTO/RPO), and what dependencies exist.
Disaster Recovery Plan (DRP)
A disaster recovery plan is a subset of BCP that specifically addresses IT system restoration after a disaster. Disasters covered include natural disasters (earthquake, flood, hurricane), technological disasters (data center fire, major equipment failure, ransomware), and human-caused disasters (sabotage, terrorism).
- Recovery location: Where will IT operations be run if the primary site is unavailable? Options range from cold sites (space with power and connectivity, no equipment) to warm sites (pre-configured but not current) to hot sites (fully operational, real-time data mirroring).
- Data recovery: How will lost or corrupted data be restored? From what backup source? With what RPO (Recovery Point Objective — maximum acceptable data loss)?
- Application restoration: In what order will applications be restored? Which are most critical? What dependencies exist between applications?
- RTO (Recovery Time Objective): Maximum time the organization can tolerate being without a specific system before unacceptable business harm results.
Incident Response Roles and NIST SP 800-61
Why Roles Must Be Policy-Defined
During an active security incident, there is no time to determine who should do what. Roles, authorities, and responsibilities must be defined in policy before incidents occur. Without pre-defined roles, incidents produce confusion, duplicated effort, missed tasks, and delayed decisions — all of which benefit the attacker and extend the damage window.
Five Incident Response Roles
| Role | Responsibilities |
|---|---|
| IR Team (technical responders) | Detect, contain, analyze, and eradicate the incident. Execute technical response procedures. Collect evidence. Own the technical aspects of the response. |
| IT Security Management | Coordinate the overall response. Escalate to senior management when scope or impact requires. Approve containment and recovery decisions that affect business operations. |
| Compliance Officers | Ensure the response meets regulatory requirements. Manage mandatory breach notifications (GDPR 72-hour notification, HIPAA notification requirements). Document compliance-relevant decisions. |
| Technical Staff (non-IR) | Provide system access, technical knowledge, and operational support during response. May be subject matter experts for specific systems being investigated. |
| User Community | Report suspicious activity, follow security instructions during the incident (e.g., "do not use email"), and cooperate with responder requests. Often the first to notice an incident. |
NIST SP 800-61 and the Incident Response Lifecycle
NIST SP 800-61 (Computer Security Incident Handling Guide) provides the framework for incident response that the Security+ exam tests. The four-phase lifecycle:
- Preparation: Establish policies, build the team, assemble tools (go bag), document baselines, create contact lists. Everything that must exist before an incident occurs.
- Detection and Analysis: Identify and characterize potential incidents. Determine whether events constitute an incident. Analyze scope and impact.
- Containment, Eradication, and Recovery: Stop the spread (containment), remove the threat (eradication), restore operations (recovery).
- Post-Incident Activity: Lessons learned, timeline reconstruction, policy and procedure updates based on findings.
Software Development Lifecycle and Change Management
Software Development Lifecycle (SDLC)
Security policies must address how software is developed and deployed. The SDLC policy ensures security is integrated into development, not bolted on after the fact. Two primary methodologies:
| Methodology | Characteristics | Security Considerations |
|---|---|---|
| Agile | Iterative, short development cycles (sprints, typically 2 weeks). Working software delivered frequently. Requirements evolve. Cross-functional teams. | Security must be integrated into each sprint. Frequent releases mean frequent deployments — security testing must keep pace. DevSecOps applies security automation in CI/CD pipelines. |
| Waterfall | Linear phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Each phase completes before the next begins. Well-documented, predictable timeline. | Security requirements must be captured in the Requirements phase; retrofitting security into later phases is expensive. Formal security review at each gate. |
Security policy for SDLC typically mandates: security requirements must be included in project requirements; security testing (SAST, DAST, penetration testing) must be completed before production deployment; security sign-off is required before release.
Change Management Policy
Change management policies govern how changes to IT systems and infrastructure are proposed, reviewed, approved, and implemented. Uncontrolled changes are a significant security risk: a misconfigured firewall rule introduced without review can open a major vulnerability.
Change management policy elements:
- Frequency: How often changes are permitted (e.g., weekly change windows; emergency changes require separate approval). Restricting change frequency reduces the risk window and ensures adequate review time.
- Duration: Time windows for implementing changes. Changes outside the window require emergency change process and additional scrutiny.
- Fallback procedures: Every change must have a documented rollback plan. If the change fails or produces unacceptable results, the fallback defines how to restore the previous state. Without a fallback, a failed change may leave systems in an undefined, potentially insecure state.
- Risk analysis: The potential security and operational impact of the proposed change must be assessed before approval.
- Approval authority: Who must approve changes based on their risk and scope (e.g., routine changes by IT manager, high-risk changes by CCB or CISO).
- Documentation: All approved changes, the rationale, and the outcome must be documented for audit purposes.
The CIA Triad Foundation
All security policies are ultimately justified by the CIA triad: Confidentiality (information is only accessible to authorized parties), Integrity (information is accurate and unmodified), and Availability (information and systems are accessible when needed). Each policy can be traced back to protecting one or more of these three properties. The AUP protects confidentiality and integrity. The BCP/DRP protects availability. Incident response policies protect all three by enabling rapid response when CIA is threatened.