D832 Managing Information Security is recorded under banner number ITAS 3032 and is worth 3 competency units. It covers developing and managing an information security program and analysing how that program relates to the wider goals of the business. D832 and ITAS 3032 are one requirement, and the course expands on the fundamentals material that precedes it. The shift is from knowing controls to running the function that decides which ones exist.
A program is a system, not a pile of controls
The move this course asks you to make is from thinking about individual protections to thinking about the machine that produces them. A security program has a charter that says what it exists to do, a scope, an owner with authority, a risk process that decides priorities, a control set, a way of measuring whether any of it works, and a cycle that reviews and adjusts. Students who list controls are answering the previous course's question; students who describe how controls get chosen, funded, implemented and reviewed are answering this one.
Alignment to business goals is the second theme and it is where most credit sits. Security spending competes with everything else an organization wants to do, and a program that cannot express its value in the organization's own terms will be underfunded regardless of how technically sound it is. That means learning to say what a control protects in terms of revenue, obligation, reputation or continuity rather than in terms of threats avoided.
Measurement is the part students find hardest and it is worth practising deliberately. Useful security measures describe program performance, not activity: how long it takes to remediate a critical finding, what proportion of systems are covered by monitoring, how quickly access is removed when someone leaves. Counting blocked attacks is activity theatre and evaluators recognise it as such.
Awareness and people run alongside. A program's weakest component is usually a process someone works around because it makes their job harder. Naming that dynamic, and designing for it, is the difference between a program on paper and one that operates.
Work here returns Competent or Not Competent, and neither letter grades nor an ordinary grade point average are recorded, and 3 competency units is how the course's weight is expressed in a six month flat-rate term.
Turning aspects into a program design
If your version of D832 uses a performance assessment, the aspects usually correspond to program components. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a well designed risk process will not carry an unaddressed measurement or awareness aspect.
Budget before drafting. Take a rubric with seven scored aspects and a target near 2,000 words. Reserve 140 words for the organization and its business objectives, and 100 for the close, leaving 1,760 across seven aspects, or roughly 251 each. Weight by demand: two aspects requiring you to design a process and justify it need 350 each, which is 700; the five remaining aspects, covering roles, controls, measurement, awareness or improvement, take 212 each, which is 1,060. Together that is 1,760.
Give every program component the same four beats: its purpose, who owns it, how it operates, and how you would know it is working. Repeating that pattern makes the document readable, ensures the measurement question is answered everywhere rather than once, and maps cleanly onto how aspects in management courses are usually written.
Reserve budget for constraints. A program designed for an organization with unlimited budget and full executive backing is not the exercise. Name what you would do with the resources the scenario implies, and say what you would do first if you got more.
Shape for a security program proposal
D832 deliverables usually design or assess a security program. These proportions fit that document.
| Section | Content | Share |
|---|---|---|
| Business context | What the organization does, what it must protect, and the objectives security has to support. | 13 percent |
| Program charter | Purpose, scope, authority and reporting line, stated so the program's mandate is unambiguous. | 14 percent |
| Risk process | How risks are identified, assessed, prioritised and accepted, and who signs the acceptance. | 18 percent |
| Control set | Controls chosen and why, mapped to risks rather than to a framework checklist. | 16 percent |
| Roles and awareness | Who does what across the organization, and how staff are equipped to comply. | 14 percent |
| Measurement | Program measures with targets, and what each one would trigger if it moved. | 16 percent |
| Close | Maturity path, the first year's priorities, and what more funding would buy. | 9 percent |
Sourcing program and management claims
Program structure, control catalogues and maturity concepts belong to published frameworks, and citing the framework rather than a summary keeps your terminology exact. Where you adopt a framework's structure, say which one and why it suits this organization, because frameworks differ in emphasis and choosing one is itself a decision worth defending.
Claims about effectiveness are empirical and need research or industry survey data with a year attached. A framework can tell you that access reviews are recommended practice; only evidence can tell you what organizations that perform them experience. Keeping those two source types apart is the clearest sign of a student who understands what evidence is for.
Cost and resourcing claims should be honest about their basis. You will rarely have real figures, and an estimate labelled as an estimate, with the reasoning shown, is stronger than a confident number with no origin. Saying that a control requires roughly one day per month of an administrator's time, and explaining why, is a defensible statement.
Scenario detail remains your best material. If the case says the organization has forty staff, one systems administrator and a regulatory obligation, those three facts constrain every recommendation you make, and using them explicitly is what stops the proposal from reading as a template.
Apply whichever citation style the task specifies and attach every source to the sentence that depends on it. Where you present a measure, give it a definition, a target and a source of data, because a measure nobody can calculate is a sentence rather than a metric.
Competent programs and returned ones
Competent submissions describe a program that could actually run in the organization described. Authority is stated, risk acceptance has a named signatory, controls trace to risks, measures are calculable, and the whole thing is sized to the resources available.
Returns cluster in four shapes. The document is a control list with a management heading. Risk acceptance has no owner, which means nothing can actually be accepted. Measures count activity rather than performance. Or the program assumes staffing and budget the scenario clearly does not have.
Maturity is the concept that turns a static proposal into a plan. A program does not arrive complete; it starts with the few things that matter most and adds capability as the organization can absorb it. Describing where the program sits today, where it should be in a year, and what specifically changes between those two states is the framing that makes a proposal credible to someone who has watched security initiatives stall. It also gives you a natural way to sequence recommendations that would otherwise all compete for first place.
One check worth running: for each recommendation, name the person in the scenario who would do the work. If the same overloaded administrator appears against nine items, the program is not implementable and saying so, with a phased plan, is a stronger answer than pretending otherwise.
Nothing is deducted when performance assessment work goes back for revision, so completeness beats polish when you are deciding whether to submit, since an early submission leaves room for a revision cycle. If your section also carries an objective assessment, WGU objective assessments are proctored and our boundary is fixed: preparation only, with framework drills, measurement practice and a candid read on your preassessment result. We never sit an exam, take no part once one begins, and your portal login is never something we touch.
Program reading like a control list?
Send the D832 rubric and scenario. We rebuild it as charter, risk process, controls and measures, with word targets per aspect.
Eight mistakes that cost time in D832
- Listing controls instead of designing a program. The question is how controls get chosen and reviewed, not which ones exist.
- Risk acceptance with no signatory. Someone has to own accepted risk, by name and role, or acceptance is meaningless.
- Activity metrics. Blocked attacks and training completions measure motion. Time to remediate measures performance.
- Framework as checklist. Map controls to this organization's risks. A framework is a source of options, not an answer.
- Ignoring resourcing. A program sized for a company ten times larger will not be implemented and reads as inexperience.
- No business language. Express what security protects in terms the organization already cares about.
- Awareness as annual training. Design for the process people will otherwise work around, and say which one that is.
- Measures with no data source. If nobody can calculate it, it is not a measure.
Three questions students ask about D832
Do I need management experience?
How does this differ from the graduate cybersecurity management course?
Which framework should I base my program on?
Where D832 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.