Menu
Contact us →
Secure by Design module

Secure by Design, built into every project.

Make security decisions while the solution is being designed, not in a review the week before go-live. Cybereen gives your team a six-stage workflow from design document to signed-off security architecture.

Upload your design docs and the AI co-pilot derives the applicable controls, threats and scope. You review and commit; a living Security Architecture Document assembles as you go.

Book a walk-through See a project run through it

See Secure by Design on your own project

A 30-minute walk-through with one of our team, using a solution you are designing now.

Please tell us your name.
Please enter a valid email address.
Please add your company.
Please confirm you'd like us to contact you.

A real person replies within one business day. No marketing list.

Maps to → Essential 8 ISO 27001 ISO 42001 APRA CPS 234 NIST CSF 2.0 the SCF control catalogue

Designed in, not bolted on

What is Secure by Design?

Secure by Design is an approach where a system's security is decided while it is being designed, not checked after it is built. Threats are identified, controls chosen and exceptions agreed before anyone builds.

It's the approach ASD's Australian Cyber Security Centre promotes in its Secure-by-Design Foundations. Cybereen turns it into a workflow your project teams actually follow.

Security reviewed at the end

  • Security sees the design after it's built
  • Threats found late mean costly rework
  • Controls chosen from scratch every project
  • Exceptions get quietly skipped
  • Architecture document written after the fact

Secure by Design in Cybereen

  • Security shapes the design before build starts
  • Threats identified against each component at design time
  • Approved patterns bring their controls with them
  • Every exception has an owner, a compensating control and an expiry
  • The document builds itself from the work

The principles of Secure by Design

  1. Decide security at design time: before build starts, when a change costs a conversation rather than rework.
  2. Model threats per component: every part of the architecture gets its threats and a control that answers each one.
  3. Reuse approved patterns: proven building blocks such as SSO or central logging bring their controls with them.
  4. Make exceptions explicit: every skipped control has an owner, a reason, a compensating control and an expiry.
  5. Assure independently: the person who built a control isn't the one who signs it off.
  6. Keep one living record: the security architecture document is produced by the work, not written afterwards.

Cybereen already tracks compliance once a system exists. Secure by Design adds the design stage in front of it, and every decision writes straight through to your existing Applied Controls, Risks and Evidence. Nothing is re-keyed, and there's no second system to keep in sync.

See it work

How Secure by Design works: one project, six stages.

Follow an example project: a patient self-service portal that handles personal health data.

Cybereen Secure by Design project overview - the six-stage progress bar across the top, live counts, go-live readiness and the Security Architecture Document chapter status

  1. Describe the solution and its data

    You: name the solution and answer a short intake.

    Cybereen: suggests the data classification straight from your description.

    Result: project overview & classification

  2. Scope components and security domains

    You: upload solution-design.pdf.

    Cybereen: identifies the components and the security domains in scope, drafted for you to edit.

    Result: in-scope domains & architecture node map

  3. Assess threat modelling and controls

    You: accept, edit or dismiss each suggestion.

    Cybereen: drafts threats for each component and maps each one to the SCF control that mitigates it. Exemptions and project risks flow straight into Cybereen Risks.

    Result: threat table with owner, state and due date How AI-assisted threat modelling works →
    Cybereen Secure by Design Assess stage - the AI Insights panel drafting a threat and an exemption for a patient portal, each with Accept or Dismiss

  4. Build security patterns and implementation

    You: apply approved patterns and track implementation by owner and date.

    Cybereen: the SSO pattern brings its MFA, session and access-review controls, so you only assess what's different.

    Result: control status per component, exceptions logged Browse reusable security patterns →

  5. Go-live readiness built versus assured

    You: work through the readiness checklist.

    Cybereen: works out readiness from the real status of each control, and one hard gate holds go-live until every item is cleared. Built is not the same as assured.

    Result: go / no-go view, gaps visible

  6. Handover owners and residual risk

    You: confirm the long-term owners and accept the residual risk.

    Cybereen: writes the closure summary: scope, controls, exemptions and residual risk.

    Result: named owners after launch
What you get

The Security Architecture Document writes itself.

You don't write it. Doing the work produces it.

  • Every chapter shows its real state. Confirmed, Draft or Empty is derived from the underlying work, never typed in.
  • Updates as the project changes. Scope, threats, controls, exemptions and residual risk assemble as you commit them.
  • Ready for the board and auditors. One record of how the solution was designed to be secure.
Explore the Security Architecture Document
Security Architecture Document · Patient portal
1. Overview & classificationfrom DescribeConfirmed
2. Scope & architecture nodesfrom ScopeConfirmed
3. Threats & controlsfrom AssessDraft
4. Exceptions & residual riskfrom BuildDraft
5. Go-live readinessfrom Go-liveEmpty
6. Handoverfrom HandoverEmpty

Three Secure by Design rules the module enforces

AI drafts. People commit.

The co-pilot only writes suggestions. Nothing becomes a control, a risk or part of the design document until someone approves it.

Built isn't assured.

Implemented and independently verified are tracked separately, and no one can assure a control they built themselves.

No silent gaps.

Every exception has an owner, a reason, a compensating control and an expiry date. A skipped control is never invisible.

Questions before your next design

Secure by Design FAQ

What is Secure by Design?
Secure by Design is an approach where a system's security is decided while it is being designed, not checked after it is built. Threats are identified, controls chosen and exceptions agreed before anyone builds. It is the approach promoted by ASD's Australian Cyber Security Centre in its Secure-by-Design Foundations. Cybereen turns it into a six-stage workflow your project teams follow.
What are the principles of Secure by Design?
1. Decide security at design time: before build starts, when a change costs a conversation rather than rework. 2. Model threats per component: every part of the architecture gets its threats and a control that answers each one. 3. Reuse approved patterns: proven building blocks such as SSO or central logging bring their controls with them. 4. Make exceptions explicit: every skipped control has an owner, a reason, a compensating control and an expiry. 5. Assure independently: the person who built a control isn't the one who signs it off. 6. Keep one living record: the security architecture document is produced by the work, not written afterwards.
What is an example of Secure by Design?
A patient self-service portal that handles health records. Before build, the team identified threats such as a stolen session token or parameter tampering exposing another patient's record, and mapped each to a control like session termination or object-level authorisation. They applied the approved SSO pattern to bring in MFA, logged a time-limited exception with a compensating control, and go-live waited until each control was independently assured.
How does the AI derive controls from my documents?
You upload a design document, architecture write-up or intake brief. The co-pilot reads it and drafts the applicable SCF controls, the threats at each component and a suggested scope and classification - mapped to your solution. Every draft is presented for you to accept or dismiss; nothing is committed to a control, risk or the design record until a human confirms it.
Is this a separate platform to learn?
No. Secure by Design is a module on the Cybereen platform you already run. It reuses your Applied Controls, Risks, Evidence, the SCF catalogue and your framework mapping - and writes design-stage decisions straight through to them. There's no second system to keep in sync.
What does "built is not assured" mean in practice?
A project team can mark a control implemented. That is not the same as it being assured. Assurance is a separate, recorded act by a different person on the Cyber side - and the platform stops anyone assuring a control they implemented themselves. Your go-live readiness reflects what is actually assured, not just what someone says is done.
What do we get out of it at go-live?
A living Security Architecture Document assembled from the work - solution overview, scope, threats and controls, exceptions and residual risk, and readiness - plus every control and risk already flowed into your platform. Board- and auditor-ready, produced by the design-stage work you were doing anyway rather than written up afterwards.
Do we have to use the AI co-pilot?
The guided journey and the living document work end to end whether or not you use the co-pilot - you can enter everything yourself. The AI is there to do the heavy lifting and get you to a first threat model far faster; it never removes the human decision.

Design your next solution secure from day one.

See it on one of your own projects in a 30-minute walk-through.

Book a walk-through → See the whole platform