System Design

From wish list to blueprint

Software works the same way. If the design doesn’t specify a control, developers won’t build it. That’s why the auditor cares so much about this phase.

What design produces

• Architecture: the components, platforms and environments, and how they talk to each other
• Data design: database tables, the data dictionary, data flows, how long data is kept
• Interface design: screens, reports, APIs, file formats
• Processing logic: business rules, calculations, workflows
• Control design: input validation, processing checks, output reconciliation, access roles, segregation of duties, audit trails, error handling
• Security design: login, permissions, encryption, logging
• Test design: how each requirement will be proven to work

Controls are specified here

The auditor’s questions at design time:

• Are input, processing and output controls specified for critical data?
• Do audit trails record who did what and when, with before and after values for sensitive changes?
• Do the access roles support segregation of duties?
• Are error handling and exception reporting defined?
• Do interfaces include checks such as record counts and control totals?

The auditor reviews whether controls are designed in. They don’t review the code at this stage.

The design review

Before coding starts, a formal review checks the design against the requirements. Users, QA, security, operations and sometimes the auditor take part. Once approved, the design becomes a baseline: later changes go through change control.

Example. In a design review for a claims system, the auditor notices that the same user can create and approve a claim, and that changes to payee details aren’t logged. Both get added to the design before any code is written, at almost no cost.

When you buy instead of build

Many organisations buy a package or a SaaS product rather than build their own. Design work then looks like this:

• Fit-gap analysis: where the package already meets the requirements, and where it doesn’t.
• For each gap, decide: configure it, change the process, customise the package, or live with a workaround.
• Design the interfaces to other systems and the data migration.

Heavy customisation makes every future upgrade harder and more expensive. Changing the business process to fit the package is often the better answer.

How the exam asks about it

In short

• Design translates requirements into a technical solution: architecture, data structures, interfaces, processing logic and controls.
• Controls such as input validation, processing checks, audit trails and access roles are specified during design.
• A formal design review, with users, QA, security and possibly the auditor, catches gaps before coding.
• The design should be traceable to requirements; anything unmet is identified before build.
• For purchased software, the equivalent work is fit-gap analysis and configuration design.
• Design decisions affect testability, maintainability and security for the system's whole life.

Exam traps

• Design approval should come before coding starts.
• Audit trails that aren't designed in are rarely added later.
• Customising purchased software heavily increases upgrade cost and risk.
• The auditor reviews whether controls are designed, not the code itself.

Slides

Click the slide and use the arrow keys. F toggles full screen.