E025 Cloud and Network Security Models carries the banner number ITCL 2200 and is worth 4 competency units. It covers the fundamentals of securing cloud and hybrid networks, the threats that are emerging against them, the tooling used to detect and stop those threats, and the advanced defense techniques and practices that reduce risk. E025 and ITCL 2200 are one requirement. The word doing the work in the title is models: this course is about the security architectures organizations adopt, not a tour of individual products.
Hybrid is where the interesting failures live
A purely on premises network has one perimeter and one set of controls. A purely cloud environment has a different set, defined by the provider and the tenant together. Hybrid has both plus the seams between them, and the seams are where this course spends its attention, because that is where real incidents happen. Connectivity between environments, identity that spans both, logging that stops at a boundary, and controls that assume a perimeter that no longer exists.
Shared responsibility is the concept that makes the rest coherent. In every cloud service model, some controls belong to the provider and some belong to you, and the split moves depending on the model. Getting that split wrong produces the two classic outcomes: assuming the provider secures something it does not, or duplicating a control the provider already enforces while leaving a real gap open elsewhere.
Security models in the modern sense have moved away from trusting a location. Assuming that being inside the network means being trustworthy fails in an environment where a workload might be running on infrastructure you do not own, reached by a user on a device you do not manage. The course asks you to reason from identity, from the sensitivity of the resource and from continuous verification rather than from network position, and submissions that still argue from the perimeter alone read as dated.
Tooling matters, but as instrumentation for a model rather than as a shopping list. Detection tools, network monitoring, policy engines and posture management each answer a question. A submission that names the tools without saying what question each answers is describing equipment rather than a defense.
Outcomes here read Competent or Not Competent, WGU issues no letter grades and keeps no ordinary grade point average, and the 4 competency units of E025 fall inside a flat rate six month term.
Turning scored aspects into a security architecture plan
If your version of E025 is assessed by a performance assessment, the aspects your evaluator scores define the sections and their relative weight. WGU requires a score of 2 in every aspect for a task to pass, and each aspect is judged alone, so a strong threat analysis will not carry an unaddressed tooling or mitigation aspect.
Do the budget before drafting. Assume a rubric carrying seven scored aspects and a target near 2,200 words. Reserve 170 words to establish the environment, its data and its connectivity, and 110 for the close, leaving 1,920. Three aspects that require you to analyze a threat and specify a control against it take 360 words each, or 1,080, because each needs the threat, the exposure it uses, the control and the residual risk. The four remaining aspects, typically covering the security model itself, shared responsibility, tooling and monitoring, take 210 each for 840. The two figures add to 1,920 exactly.
Inside every control paragraph, use one fixed order: the asset at risk, the threat against it, the control you apply, where the control sits, and what risk remains. Applying that pattern consistently makes each paragraph checkable and stops the common drift where a paragraph starts as analysis and ends as a product description.
Keep budget for residual risk. Controls reduce risk and do not remove it, and saying what remains after your control is applied is the sentence that most reliably separates competent security writing from confident security writing.
Shape for a hybrid security architecture document
E025 deliverables usually secure a described environment that spans on premises and cloud. These proportions carry that document.
| Section | What belongs there | Share |
|---|---|---|
| Environment and data | What runs where, what connects to what, and what data is sensitive. | 11 percent |
| Security model | The model you are applying and why it fits this environment rather than another. | 15 percent |
| Shared responsibility | Which controls belong to the provider and which to the organization, per service model in use. | 12 percent |
| Threat analysis | The threats that matter here, with the exposure each one would use. | 18 percent |
| Controls and placement | Each control, what it stops, and exactly where in the architecture it sits. | 20 percent |
| Detection and monitoring | What is logged, where logs go, what triggers an alert and who acts on it. | 16 percent |
| Close | Residual risk and the control you would add next with more budget. | 8 percent |
Sourcing threat and control claims
Security writing has a specific credibility problem: threat claims age fast and vendor sources have an interest. Handle it by separating three source families. Threat behavior comes from recognized threat intelligence, published advisories and government or industry security bodies. Control guidance comes from published frameworks and benchmarks. Platform behavior comes from provider documentation, cited with the date.
Treat vendor material as evidence about the product, not as evidence about the threat. A vendor page describing what its tool detects is a fair source for what the tool does and a weak source for how common the attack is or how effective the category of control proves to be.
Where you claim a threat is emerging, say emerging according to whom and when. A dated advisory or an annual threat report gives the claim a spine. An undated assertion that attackers are increasingly doing something is the weakest sentence in most student security papers, and it is easy to fix.
Use the citation style your task specifies and cite at the point of the claim rather than banking citations at the end of a section. Where you map controls to a framework, name the framework and the specific control identifier, because a mapping without identifiers is not a mapping.
What earns Competent, and what comes back
Competent submissions connect every control to a threat and every threat to something in the described environment. They state the shared responsibility split explicitly rather than assuming it. They place controls somewhere specific instead of recommending them in general. And they say what risk survives the design.
Returns have familiar shapes. Threats are listed generically with no link to this environment. Controls are recommended without a location, so nobody can tell what traffic or identity they would actually govern. The shared responsibility discussion is a definition rather than an application. Monitoring is mentioned without saying who responds. Or the model is named in the introduction and then contradicted by a design that trusts network position.
A useful last pass: for each control in your document, write the sentence beginning with the threat it stops. Any control that will not accept that sentence is in the paper because it is good practice in general, which is not the same as being justified here.
Revised and resubmitted performance assessment work carries no grade penalty at WGU, so send it the moment every aspect has a real answer. Objective assessments at WGU are proctored, and our boundary does not move: preparation only, meaning control mapping drills, terminology work, scenario practice and an honest read of your preassessment result. We do not sit assessments, we take no role while one is under way, and we never ask you for portal credentials or hold them.
Controls listed but not placed?
Send the E025 rubric and your scenario. We rebuild it threat by threat, with each control given a location and a residual risk statement.
Six mistakes that cost time in E025
- Generic threat lists. A threat that is not tied to something in the described environment cannot justify a control in that environment.
- Controls with no placement. Say where it sits and what it governs. A control floating in the abstract is unscoreable.
- Getting shared responsibility backwards. The split changes by service model. State it for each model actually in use.
- Arguing from the perimeter. In a hybrid environment, location is not trust. Reason from identity and resource sensitivity.
- Vendor pages as threat evidence. Fine for what a tool does, weak for how prevalent an attack is or how well a control class works.
- No residual risk. Every design leaves something open. Naming it is competence, not weakness.
Three questions students ask about E025
How much networking do I need before this course?
Do I have to pick one security model and stick to it?
Is E025 the same course as ITCL 2200?
Where E025 sits in WGU's programs
The July 2026 catalog places this code in 4 current WGU programs. 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.