Cybersecurity in Project Management Planning Notes (UNISA MNG 0001 / CUT IT Project Management & Risk Modules)

Cybersecurity in project management planning is the discipline of designing, documenting, and governing security controls from the earliest planning artifacts through delivery, change, and closure. In practical terms, it ensures that risks such as data leakage, ransomware, supply-chain compromise, and misconfigured access are considered as first-class project concerns—alongside cost, time, quality, and scope. These exam-style notes integrate project planning techniques (scope, schedule, governance, risk, procurement, and compliance) with cybersecurity requirements (controls, threat modeling, IAM, logging, incident readiness, and assurance).

This guide is written to match what South African students typically encounter in modules such as UNISA MNG 0001 (Project Management)-style planning concepts, and CUT-style computing/IT project management risk planning. It focuses specifically on what to include in project planning documents (e.g., project charter, scope statement, risk register, stakeholder register, information security plan, and procurement plan) and how to justify them during assessments and viva-style questions.

UNISA MNG 0001 Exam Notes: Building a Cybersecurity-Aware Project Plan

UNISA-aligned project management planning often emphasizes structured artifacts: project charter, scope, schedule, risk management plan, stakeholder management, and governance. When cybersecurity is “bolted on” later, projects experience avoidable rework: security exceptions, late architecture changes, and stalled releases. The goal in MNG 0001-style planning is to incorporate security into the baseline plan so that every work package and approval decision references security outcomes.

Cybersecurity goals that must appear in the project charter

A project charter is where the project’s purpose, boundaries, governance, and high-level risks are established. For cybersecurity-aware planning, the charter should explicitly state security objectives and the authority structure for security decisions.

Common cybersecurity objectives suitable for planning artifacts (and exam answers) include:

• Protect confidentiality of sensitive data (customer records, employee data, credentials, internal IP).
• Maintain integrity of project deliverables (code, configuration, documents, test evidence).
• Ensure availability of services and critical project environments (CI/CD pipelines, production-like environments, management consoles).
• Reduce likelihood and impact of incidents through preventive and detective controls.
• Achieve compliance with applicable legal and regulatory obligations (e.g., POPIA for personal information, if relevant to the project’s data types).

Even if the module exam does not require legal detail, students can score marks by linking security objectives to project success criteria. In planning, this means security is not treated as “extra work”—it is treated as part of “definition of done.”

Exam-friendly phrasing: The project’s success metrics must include security acceptance outcomes, not only functional requirements.

Defining scope with security constraints (scope statement linkage)

A scope statement clarifies what is in and out of the project. Cybersecurity planning requires that the scope statement include security constraints such as:

• Required encryption standards for data at rest and in transit.
• Minimum authentication controls (e.g., multi-factor authentication for administrative access).
• Logging and monitoring requirements (e.g., centralized log collection, retention period).
• Secure configuration baselines (e.g., using hardening guides).
• Vulnerability management expectations (e.g., scanning frequency, remediation SLAs).

A common planning mistake is writing scope in purely functional terms (“build a web portal”) without specifying security acceptance. When this happens, later implementation teams interpret security differently, and stakeholders dispute “how secure is secure enough?”

To avoid that, an exam-grade scope statement often includes a security boundary such as:

• What environments must be hardened (development, test, staging, production).
• Which data categories are in scope (personal information, financial records, operational secrets).
• Which threat scenarios the project must be ready to handle (credential theft, insider misuse, malware).

Security requirements mapping to work breakdown structure (WBS)

In planning, the WBS translates scope into manageable work packages. Cybersecurity items must be broken down into tasks that can be scheduled, resourced, and tested.

A useful way to structure a cybersecurity WBS for projects is to include work packages in these areas:

1. Design & architecture security
   • Threat modeling workshop
   • Security reference architecture selection
   • Data classification design
2. Identity & access management (IAM)
   • Role design and least privilege implementation
   • MFA rollout and administrative access controls
3. Secure SDLC / secure delivery
   • Secure coding standards
   • Code review workflow with security gates
   • Dependency scanning and SCA (software composition analysis)
4. Infrastructure & configuration security
   • Baseline hardening
   • Network segmentation
   • Secure secrets management (no plaintext secrets in repos)
5. Monitoring, logging, and detection
   • Central logging setup
   • Alert rules and escalation paths
6. Testing & assurance
   • Security testing (SAST/DAST, pen test readiness)
   • Evidence collection for audits
7. Incident readiness
   • Incident response playbooks
   • On-call assignment for security incidents
8. Training & governance
   • Security awareness for project team
   • Change management approvals for security-relevant changes

For exam practice, write these as WBS items with deliverables and acceptance criteria. If your assignment uses a template that requires WBS “dictionary” entries, include:

• Responsible role (e.g., security engineer, project manager, developer lead)
• Definition of done (what evidence proves completion)
• Dependencies (e.g., IAM design must be ready before deployment tasks)
• Verification method (scan logs, review records, test reports)

Threat modeling as a planning input (not a late-phase activity)

Threat modeling can be done early—during planning—and should feed directly into the risk register and requirements.

A practical approach is to use a lightweight model that still produces actionable controls:

• Identify assets: data stores, APIs, admin consoles, CI/CD pipelines.
• Identify entry points: web forms, APIs, third-party integrations.
• Identify trust boundaries: between client and server, between services, between on-prem and cloud.
• Identify threats: unauthorized access, injection flaws, data exfiltration, supply-chain compromise.
• Choose mitigations: IAM rules, input validation, network segmentation, dependency management.

For planning, the output of threat modeling must be documented as:

• A list of key threats with severity ratings.
• Which mitigations are planned as work packages.
• Which residual risks are accepted (and by whom).

Counter-argument students sometimes make: “Threat modeling takes too long.”
Exam-grade rebuttal: Threat modeling can be scaled for project size. Even a workshop that outputs threat categories and mitigation decisions improves planning quality and reduces rework.

Risk register: integrating cybersecurity threats with project risks

A standard risk register often includes probability, impact, owner, response, and status. Cybersecurity risks should be treated similarly to schedule or budget risks, with additional structure:

• Probability and impact scoring should be aligned with project risk thresholds.
• Owners may include information security personnel, not only project managers.
• Response strategies should include prevention, detection, containment, recovery, and assurance activities.

Examples of cybersecurity risks suitable for a planning-stage risk register:

• Risk: Unauthorized access due to weak IAM configuration.
  Mitigation: Least privilege roles, MFA for admin actions, regular access reviews.
  Detection: Alerts for anomalous admin logins.
• Risk: Vulnerabilities in third-party libraries introduce exploitable weaknesses.
  Mitigation: Dependency scanning, patch management cadence, approved component list.
• Risk: Ransomware affects production-like environments and disrupts testing.
  Mitigation: Backups tested for restore, endpoint hardening, EDR deployment.

A high-scoring planning answer includes not only mitigations but security acceptance triggers such as:

• “No production deployment until vulnerability scans meet defined thresholds.”
• “Release cannot proceed if critical IAM misconfigurations are detected.”

Stakeholder management for cybersecurity ownership

Stakeholders often include the project sponsor, customer representative, development team, vendors, compliance officers, and security teams. In planning documents, cybersecurity ownership must be explicit.

Add a stakeholder register entry that clarifies:

• Who approves security exceptions.
• Who is responsible for validating controls.
• Who handles incident escalation decisions.

A common failure mode is unclear authority. For example, developers might implement controls, but no one has formal authority to sign off on security. That delays delivery and creates disputes.

To fix this in planning, define an approval pathway such as:

1. Security engineer validates control configuration.
2. Project manager checks schedule and dependencies.
3. Sponsor/custodian signs off on residual risk acceptance.
4. Change control records security-relevant modifications.

CUT IT Project Management & Risk Notes: Planning Security for Delivery, Change Control, and Governance

In a CUT-style IT project management context, students often focus on systems thinking: delivery pipelines, governance processes, risk control, and practical engineering constraints. This section emphasizes operationalizing cybersecurity within planning—especially around delivery processes, change control, vendor management, and governance.

Building an information security plan as a deliverable (security-specific planning artifact)

Most project plans are too general to guide secure execution unless a project-specific information security plan exists. In planning, the project manager should produce or sponsor an information security plan that includes:

• Scope of systems and data in the project.
• Security architecture constraints (encryption, authentication, authorization model).
• Secure SDLC procedures.
• Logging/monitoring plan and retention.
• Vulnerability management and remediation approach.
• Secure configuration standards for infrastructure.
• Incident response alignment (how this project integrates with broader incident response).
• Responsibilities (RACI or equivalent) for security tasks.

Exam tips: In your written answers, refer to the security plan as a project deliverable. This shows that cybersecurity is integrated into project management planning rather than being an informal engineering concern.

Secure SDLC planning: turning policies into gates

Cybersecurity policies are only useful if they become part of daily execution. In a project plan, the SDLC should define checkpoints and acceptance criteria.

A planning-oriented secure SDLC includes:

• Requirements phase
  • Security requirements defined with traceability (even if informal traceability).
• Design phase
  • Threat model output is translated into control requirements.
• Build phase
  • Use secure coding standards.
  • Require code review with a security checklist (e.g., input validation, authZ checks).
• Integration phase
  • Run SAST and dependency scanning gates.
• Test phase
  • Execute DAST/penetration testing (at least readiness and targeted testing).
• Release phase
  • Confirm vulnerability thresholds and configuration baselines.
• Post-release
  • Monitor logs, handle vulnerabilities discovered in production-like environments.

To keep it exam-accurate, define the “gate concept”:

• If gate criteria are not met, the release is blocked or redirected to remediation backlog.
• Every gate has evidence outputs (scan reports, review records, test logs).

Change control: planning how security changes are approved and tracked

Change control is frequently where cybersecurity fails. For example, a small change to authentication logic can introduce a critical flaw, but if the plan treats it like any other change, security review may be skipped.

A cybersecurity-aware change control process includes:

• A classification rule: security-relevant changes require security review.
• A risk re-evaluation step: when architecture/security assumptions change.
• Updated documentation: threat model, risk register, and architecture diagrams updated.
• Evidence retention: approvals, test results, scan results.

Example classification rule (suitable for planning documents):

• Category A (security critical): authentication, authorization, encryption settings, logging, secrets management, firewall rules, access control changes.
• Category B (security relevant): changes that affect input handling, API endpoints, data transformation, integrations with external services.
• Category C (non-security relevant): UI-only changes with no data handling changes.

In the exam, you can score marks by saying: “Change control must link to the risk register and security plan; otherwise the plan decays over time.”

Governance: establishing decision bodies and escalation paths

Governance is often described as “committees” in coursework. In cybersecurity planning, governance must include decision points that allow fast action when threats appear.

A practical governance structure in project planning includes:

• Security working group: reviews risks, approves security design decisions.
• Steering committee / project board: approves budget and schedule impacts related to security.
• Incident response escalation contact: a named role (security lead) responsible for incident decisions.
• Vendor governance: review and approval of vendor security postures.

Even if your exam does not demand formal governance models, you should demonstrate that cybersecurity planning includes:

• who decides,
• who approves,
• who escalates,
• and what triggers escalation.

Vendor and supply-chain risk planning (procurement integration)

Many IT projects depend on third-party vendors: cloud providers, SaaS components, managed services, contractors, and libraries. Planning must integrate procurement decisions with cybersecurity requirements.

Vendor cybersecurity planning artifacts often include:

• Vendor security questionnaire (baseline controls).
• Contractual security requirements (logging, breach notification, access controls).
• Audit rights or evidence requirements (penetration testing reports, compliance attestations).
• Secure integration requirements (API authentication, rate limiting, least privilege).

A planning risk example:

• Risk: Vendor SaaS account compromise leads to data exfiltration.
  Mitigation: SSO with MFA, IP allowlisting for admin, audit logs accessible to project, defined breach notification timelines in contract.

A strong exam answer includes how the procurement plan and risk register interact: procurement requirements reduce risks; risks that remain must be accepted or compensated through additional project controls.

Data governance planning: classification, handling, and retention

Cybersecurity in planning includes data governance. Students often mention “protect data” generically; higher marks come from specifying data classification and handling processes.

A simple classification model for planning documents might include:

• Public
• Internal
• Confidential
• Restricted

For each class, specify:

• allowed storage locations,
• required encryption,
• allowed access roles,
• retention requirements,
• logging requirements.

Then include these as constraints in the project plan. For example:

• “Restricted data cannot be stored in development environments without encryption and access approvals.”
• “Confidential logs must be retained for a defined period to support investigations.”

In exams, if you cannot name specific retention durations, you can still demonstrate knowledge by requiring retention in the plan and linking it to incident investigations and compliance needs.

Testing strategy planning: assurance aligned to risks and gates

A cybersecurity planning section should also detail assurance activities:

• Threat model-derived test cases.
• Security testing coverage (SAST, DAST, configuration validation).
• Evidence requirements: vulnerability scan reports, penetration testing summaries, risk acceptance records.

A robust plan ensures assurance is not random. It is based on:

• top risks from the risk register,
• systems and assets identified during planning,
• maturity level of the project team and vendor.

UNISA + CUT Case-Focused Notes: Incident Readiness, Logging, and Recovery in Planning Documents

Project management planning that includes cybersecurity is not complete unless it includes what happens when something goes wrong. Incident readiness, logging, and recovery planning must be documented so the team can respond quickly and effectively during delivery and after release.

Incident response planning embedded in the project plan

Incident response (IR) planning should be included as an output of planning work, not just “have an IR plan somewhere else.” The project plan should define:

• incident categories relevant to the project,
• roles and responsibilities,
• communication channels,
• decision timelines,
• evidence collection procedures,
• post-incident reviews.

A planning-level IR should include at least:

1. Detection triggers
   • Alert from monitoring (e.g., suspicious login, malware detection).
   • Unusual data transfer patterns.
   • Vulnerability scan finds critical severity.
2. Triage
   • Determine scope: which systems and accounts are affected.
   • Preserve evidence: logs, system states, relevant artifacts.
3. Containment
   • Disable compromised accounts (with approval if needed).
   • Isolate affected services and block suspicious traffic.
4. Eradication and recovery
   • Patch exploited vulnerabilities.
   • Restore systems from tested backups.
   • Validate integrity (re-scan for vulnerabilities, confirm service configurations).
5. Lessons learned
   • Update risk register.
   • Update threat model.
   • Update secure SDLC gates to prevent recurrence.

In exam answers, the highest value comes from linking IR steps to project governance and change control. For example, recovery might require changes—those changes must pass a fast-track security approval workflow.

Logging and monitoring planning: what to log, where, and why

Logging is one of the most exam-favored areas because it’s concrete and maps well to cybersecurity goals. Planning must address:

• what events to log,
• log sources (application, OS, network, IAM, CI/CD),
• log destinations (central logging),
• retention,
• access control to logs,
• correlation and alerting rules.

A planning-ready log scope for an IT project often includes:

• Authentication and authorization events
  • successful/failed logins,
  • MFA challenges,
  • privilege changes,
  • admin actions.
• Data access events
  • downloads of confidential files,
  • large data export actions,
  • access to sensitive database records.
• System and application events
  • service restarts,
  • errors indicating possible exploit attempts,
  • exceptions related to input validation.
• Infrastructure/network events
  • firewall rule changes,
  • unusual network connections,
  • blocked traffic patterns.

A common exam-grade detail: logs must be protected. If attackers tamper with logs, incident investigation fails. Therefore, the plan should specify:

• role-based access to logging systems,
• integrity protections where possible,
• restricted credentials for log ingestion services.

Backups and recovery planning: ensuring resilience during delivery

Backups are sometimes treated as an operational topic rather than project planning. In cybersecurity project planning, backups are a security resilience control.

A planning document should define:

• backup schedule (e.g., hourly/daily)
• backup scope (databases, file storage, configuration)
• encryption of backups
• retention period
• restoration testing frequency
• recovery time expectations (RTO/RPO) if the course expects these terms

Even if the exam doesn’t require numeric RTO/RPO values, include them as target concepts with a plan to define them.

To demonstrate depth, include restoration testing as a scheduled activity:

• “Perform periodic restore tests into a staging environment.”
• “Validate application integrity and security configurations after restore.”
• “Store evidence of restore test results.”

Ransomware scenario planning (example-driven exam response)

A strong exam answer includes at least one realistic scenario. Consider a project that maintains a staging environment for testing and CI/CD pipelines. During delivery, ransomware hits endpoints or encrypts configuration and data stores.

Planning response:

• Pre-attack controls:
  • segmented networks between CI/CD, staging, and production-like systems,
  • endpoint protection agents,
  • strong credential management and MFA,
  • least privilege for CI/CD tokens.
• Detection:
  • file integrity alerts,
  • unusual encryption behavior signals,
  • mass changes to critical directories.
• Containment:
  • revoke CI/CD tokens quickly,
  • isolate infected hosts,
  • disable compromised accounts.
• Recovery:
  • restore from encrypted backups,
  • re-deploy secure configuration baselines,
  • rerun integrity scans and vulnerability checks.
• Project management impact:
  • update schedule due to environment restoration,
  • record downtime and lessons learned,
  • adjust risk register probabilities for ransomware-related risks.

In the planning context, the key is to show that the project manager anticipates schedule and resource impacts due to security events, and that the plan includes response steps that do not rely on improvisation.

Post-incident reporting integrated into lessons learned and continuous improvement

After an incident, cybersecurity should improve the project plan itself. Include in planning documents:

• incident report template
• root cause analysis process
• updates to threat model and security requirements
• updates to risk register (new threats, changed probabilities)
• updates to SDLC gates and checklists
• training updates for affected roles

This ensures cybersecurity maturity grows across the lifecycle instead of ending at “incident closure.”

Stakeholder, Compliance, and Documentation Notes for Cybersecurity Planning (South African Context)

South African cybersecurity planning in IT project management is closely tied to information protection obligations and professional governance expectations. Even when a course module is primarily project management, exam markers value students who show awareness of compliance and documentation rigor because it strengthens governance credibility.

Documentation set: what examiners expect to see in a complete planning package

A cybersecurity-aware project planning package typically includes these documents or equivalents:

• Project charter with security objectives and high-level risks.
• Scope statement with security constraints and boundaries.
• Risk register containing cybersecurity risks with response strategies.
• Stakeholder register with security approval and escalation roles.
• Information security plan (security controls deliverable).
• Threat model summary feeding requirements and risks.
• Secure SDLC plan with gates and evidence requirements.
• Change control procedure specifying security-relevant categories.
• Procurement/vendor security requirements integrated into contracts.
• Logging and monitoring plan with retention and access control.
• Incident response plan and communication/triage procedure.
• Testing/assurance plan derived from risk priorities.
• Training plan for the project team.

In an exam response, listing these documents in a structured way demonstrates mastery because it aligns with how organizations operationalize cybersecurity.

Linking compliance and security planning without overcomplicating legal details

Students sometimes either ignore compliance or over-focus on legal citations. A balanced approach for project planning notes is to describe:

• what compliance requirements imply for security controls,
• how controls get planned and evidenced,
• how audits happen in the project lifecycle.

For example, personal data protection obligations generally imply:

• access control requirements,
• encryption expectations,
• breach notification readiness,
• retention and deletion controls,
• auditability via logging.

You don’t need to quote statutes verbatim in an exam, but you should show that compliance informs control design and acceptance criteria.

Building traceability: security requirements to risk and evidence

Traceability is often described in advanced engineering modules, but it also matters in project management planning. A simple traceability model that fits exam writing is:

• Security requirement → control implementation work package → verification method → acceptance evidence.

Example traceability chain:

• Requirement: “Administrative actions require MFA.”
  → Work package: IAM configuration and MFA enrollment process
  → Verification: IAM configuration checks and test log evidence
  → Acceptance evidence: signed configuration validation report + test screenshots/log extracts (as per course expectations)

This reduces the probability of security disputes at handover time. In planning, you can mention that evidence is collected during each milestone so closure does not become a scramble.

RACI for security planning roles (RACI as a project management tool)

A RACI matrix clarifies responsibility and approval authority. In cybersecurity planning, an example distribution might look like:

• Project Manager: Responsible for integrating security work into schedule and governance; Accountable for planning completeness.
• Security Engineer/Information Security Lead: Responsible for security architecture, control design, validation criteria.
• Developers: Responsible for implementing controls in code and infrastructure configuration.
• DevOps/Operations: Responsible for logging configuration, monitoring, CI/CD security gates.
• QA/Test Lead: Responsible for executing security tests and collecting evidence.
• Sponsor/Client Representative: Accountable for accepting residual risks and approving exceptions.
• Vendor Management: Responsible for procurement security requirements and vendor evidence tracking.

In exam writing, it’s enough to show a consistent logic of responsibilities and to mention that RACI prevents ownership gaps.

Communication planning for cybersecurity stakeholders

Communication is part of stakeholder management and also part of incident readiness. In planning documents, specify communication:

• security reporting cadence (weekly risk review, milestone security review),
• escalation contacts,
• meeting agendas (risk register update, vulnerability trends, compliance status),
• decision turnaround times.

A key planning point: communication should be linked to governance triggers. For example:

• If a critical vulnerability is detected, escalation occurs immediately, and delivery gates enforce remediation prior to release.

Integrated Planning Walkthrough: A Complete Cybersecurity Plan for an IT Project (Exam-Style Templates and Scenarios)

This final section provides a consolidated, exam-style walkthrough showing how cybersecurity integrates into planning artifacts. It includes mini-templates, scenario-driven reasoning, and decision points that help learners produce high-scoring responses.

Scenario: planning an IT project that processes sensitive customer information

Assume a project will deliver a customer-facing web portal that processes Confidential customer data. The project includes development, staging environment, deployment pipeline, and integration with an external payment service.

For exam structure, you can present the planning approach as a lifecycle from charter to closeout, with cybersecurity integrated.

Step 1: Project charter—security objectives and high-level risks

In the charter, include:

• Security objectives
  • confidentiality: protect customer data,
  • integrity: prevent unauthorized modifications to deliverables,
  • availability: keep portal services operational for customer access.
• High-level security risks
  • unauthorized access through weak IAM,
  • vulnerabilities in dependencies,
  • data exfiltration through insecure APIs,
  • incident response delays due to unclear escalation.
• Governance
  • security lead validates controls,
  • sponsor accepts residual risks,
  • change control board includes security representative.

Deliverable outcome: Charter approved with security objectives and risk summary.

Step 2: Scope statement—security constraints and boundaries

Add scope constraints:

• encryption in transit (TLS) for all client-server and service-service communications,
• encryption at rest for data stores categorized as Confidential,
• MFA required for administrative access,
• secure secrets management in CI/CD (no secrets in plain text),
• centralized logging for authentication, admin actions, and sensitive data access,
• vulnerability threshold gate before production release.

Also clarify boundaries:

• development environments must not store Restricted data without approvals,
• third-party payment integration uses approved APIs with least privilege tokens.

Step 3: Threat model output—feeding requirements and the risk register

Conduct a threat modeling workshop covering:

• assets: customer database, admin console, API endpoints, CI/CD secrets,
• entry points: login page, API endpoints, webhooks,
• trust boundaries: client to server; payment integration; staging to production.

Record top threats:

• credential stuffing leading to account compromise,
• insecure authorization allowing IDOR attacks,
• injection vulnerabilities in API input handling,
• supply-chain compromise via third-party dependencies,
• logging gaps preventing incident forensics.

Translate each threat into planned mitigations work packages and risk entries.

Step 4: Risk register—probability/impact scoring and response strategies

Create risk entries such as:

• Unauthorized access due to IAM misconfiguration
  • Response: least privilege, MFA, access reviews
  • Detective control: admin login alerting
• Data exfiltration via insecure APIs
  • Response: secure coding, authorization checks, input validation
  • Assurance: API security testing
• Dependency vulnerabilities
  • Response: dependency scanning, patch policy
  • Gate: release blocked if critical vulnerabilities exceed threshold
• Delayed incident response
  • Response: incident playbooks, escalation contacts
  • Assurance: tabletop exercise before go-live

Planning requirement for exam: Mention that residual risks must be accepted by the sponsor and recorded.

Step 5: WBS—turn security controls into scheduled deliverables

Integrate security tasks:

1. IAM design and role definitions
2. MFA rollout for admin users
3. Threat modeling workshop and documentation
4. Secure SDLC gate setup in CI/CD
5. Central logging configuration
6. Vulnerability scanning tooling and thresholds
7. Security testing execution (SAST/DAST and targeted pen test readiness)
8. Incident response plan finalization and tabletop exercise
9. Vendor integration security review (payment service access model)

Assign owners and dependencies:

• IAM design must precede environment deployment.
• Logging must be configured before security testing begins.
• Vulnerability scanning thresholds must be set before release candidate is built.

Step 6: Secure SDLC gates—definition of done for releases

Define gates:

• Gate A: code review checklist completion for security-relevant changes.
• Gate B: dependency scan passes required thresholds.
• Gate C: SAST results reviewed and critical issues resolved.
• Gate D: DAST or API security tests executed with acceptable results.
• Gate E: configuration baseline validated (no default credentials, secrets stored correctly).
• Gate F: monitoring dashboards and alerts active for key events.

Exam scoring improvement: describe what evidence is retained for each gate.

Step 7: Change control—security-relevant categories and fast-track approvals

Define:

• Category A changes: authentication, authorization, encryption settings, logging configuration, secrets management.
• Category B changes: API endpoints and data transformations.
• Category C changes: UI and content with no data handling changes.

For Category A, require security engineer approval and update the threat model if assumptions change.

Fast-track during incidents:

• allow emergency changes to contain threats,
• require post-incident review and documentation.

Step 8: Logging and monitoring—what to monitor for incident readiness

Set logging sources:

• authentication service events,
• admin console actions,
• API access logs for sensitive endpoints,
• CI/CD pipeline events (deployment approvals and changes),
• infrastructure events (firewall, network anomalies).

Planning details to show maturity:

• restrict access to log systems (least privilege),
• set retention to support investigations (retain for investigation windows defined by policy),
• establish alert escalation to security lead and project board.

Step 9: Incident response—tabletop exercise integrated into the schedule

Schedule a tabletop exercise before go-live:

• scenario: suspicious admin login and possible credential compromise,
• actions: triage, containment, token revocation, log analysis, communication,
• outputs: update playbooks, confirm roles and contacts.

This ensures incident readiness is not theoretical.

Step 10: Closeout—security evidence handover and residual risk recording

At project closeout:

• confirm security gate evidence is archived,
• deliver security plan, incident playbooks, and logging configuration documentation to the operations custodian,
• record residual risks and accepted exceptions,
• ensure vendor evidence and integration security artifacts are delivered.

A strong exam answer mentions that “closeout includes security readiness handover,” not only functional documentation.

Common Exam Pitfalls and How to Answer Better

Pitfall 1: Writing cybersecurity only as “training” or “best effort”

A planning answer should include technical controls and governance processes: IAM, secure SDLC gates, logging, and incident response. Training alone is insufficient.

Pitfall 2: Risk register contains threats but no response work packages

If a risk is listed but not converted into tasks in the WBS, it’s not actionable. Examiners look for linkage: risk → mitigation → planned work → evidence.

Pitfall 3: Change control is generic

Security-relevant changes require security review and threat model updates when assumptions shift.

Pitfall 4: No incident readiness plan

Projects fail under pressure when escalation paths are unclear. Incident readiness should be in planning artifacts with role clarity and triggers.

Pitfall 5: Lack of ownership

If no one is accountable for security approvals, the project plan becomes unexecutable. Use RACI or equivalent explicit ownership.

Quick Reference: Cybersecurity Planning Checklist (Exam Summarization)

Use this as a high-yield revision list:

• Charter: security objectives + high-level security risks + governance ownership
• Scope: encryption, IAM, logging, secure SDLC, vulnerability thresholds
• Threat model: assets, entry points, trust boundaries, threats, mitigations
• Risk register: probability/impact + response strategies + owners
• WBS: security tasks with deliverables and dependencies
• Secure SDLC: code review security checklist + SAST/dependency scanning gates
• Change control: security-relevant categories + approval workflow
• Logging/monitoring: sources, retention, access control, alert escalation
• Incident readiness: playbooks + tabletop exercise + evidence collection
• Procurement: vendor security requirements + evidence tracking
• Closeout: security evidence handover + residual risk acceptance records

Summary

Cybersecurity in project management planning is achieved by embedding security objectives into core planning artifacts: charter, scope, WBS, risk register, change control, governance, procurement, and closeout. Exam-ready answers show linkage—every cybersecurity risk should map to controls, every control should map to scheduled work, and every work package should produce verifiable evidence. When incident readiness and logging are planned early, the project can respond effectively to threats without destabilizing delivery.

This integrated planning approach aligns with how South African universities structure project management learning, including modules in the UNISA MNG 0001 ecosystem and CUT IT project management and risk contexts—where students are expected to demonstrate structured thinking, traceability, and governance competence, not just list security topics.