The SDLC and Designing Controls In

The system development life cycle, and designing controls in. This lesson is about where in a project’s life the controls belong, and the exam has a firm answer: at the front, not the end.

Here is the situation. A new system reaches user acceptance testing when someone asks where the access controls and the audit logging are. They were never in the requirements, so they were never built. Adding them now means reopening the design and re-testing code, and slipping the deadline, so the team’s instinct is to launch and harden it afterwards. That instinct is the finding, and this lesson is why.

First, the shape of the life cycle. The names vary, but the exam expects the arc. Feasibility, is it worth doing. Requirements, what the system must do, functionally and in terms of controls. Design, then development. Testing, then implementation. And finally post-implementation, did it deliver. Each phase depends on the one before it, and that dependency is the whole point.

Now the economics. The cost of changing a system rises steeply as it moves down the life cycle. A control described in a requirements document is a sentence. The same control added after go-live is a change to a live system: re-analysis, re-coding, re-testing, and a release. It can cost many times more.

So the principle the exam rewards is this: design controls in, do not bolt them on. When a system is specified, its access controls, input validation, audit trails, segregation of duties and error handling should be part of the requirements, not a later thought.

Which is why a retrofit is a double problem. Controls grafted onto a finished system are usually weaker and less complete, because the architecture was not designed to hold them. And the system ran exposed until they were added. An auditor who finds controls were retrofitted after go-live carries both concerns at once.

This is where the auditor’s advisory role pays off. Reviewing the requirements for control adequacy, before anything is built, is the highest-leverage moment in the whole project. And it does not compromise independence, as long as the auditor advises rather than owns, exactly the line from the previous lesson.

So what does a good requirement look like. First, complete: nothing essential is missing.

Second, unambiguous: there is only one way to read it, so the design cannot drift from the intent.

And third, testable: you can actually prove it was met. You cannot run an acceptance test against a requirement no one can measure, which is next lesson’s problem.

Because everything downstream is built against the requirements. The design realises them, the code implements them, the tests check against them. So a requirement that is missing, ambiguous or wrong is designed in, coded in, and tested as if correct, and it emerges as a flaw in the delivered system. That is why incomplete or poorly defined requirements are the most common root cause of project failure, more than languages, hardware or sourcing. A system built well against the wrong specification is still the wrong system.

So carry this away. A control added after implementation accepts a window of exposure and is usually weaker than one designed in. Do not rush past requirements to start building. Requirements are not bureaucracy; they are the thing every later phase is measured against, and the cheapest place in the entire life cycle to get the system, and its controls, right.