Skip to content
CyberGuardCyberGuard Docs

General tips

CyberGuard is deliberately multi-paradigm: it does not force one methodology on you, because the way a twelve-person startup runs a security programme is not the way a regulated bank does. That flexibility is useful once you know the platform and paralysing on day one. What follows is the order of operations that works for most teams starting out.

A workable order of operations

Section titled “A workable order of operations”

  1. Map your organisation to domains and perimeters. Domains carry access control; perimeters scope assessments inside them. If the shape is not obvious yet, create something basic — one domain, one perimeter — and refine later.

  2. Add your users and put them in groups. Access is granted through user groups, which pair a role with a domain. Single sign-on and multi-factor authentication are both available, and both are worth turning on before the platform holds anything sensitive.

  3. Identify the assets worth protecting. Recommended rather than mandatory, but every later conversation about risk gets sharper once assets exist.

  4. Enumerate the controls you already run. Not the ones you intend to build — the ones operating today. Most teams are further along than their first self-assessment suggests.

  5. Define your baseline. Pick a framework, pick the controls that matter, create the ones that are missing. Focus on the basics before the exotica.

  6. Get the actions implemented, and reflect that in the audit. The action plan is the engine; the audit is the readout.

  7. Run a contextual risk assessment. Now that assets and controls exist, a risk assessment describes your situation instead of a generic threat list.

  8. Share the insights. Review priorities with the organisation and keep the compliance process moving. A programme nobody reads decays within a quarter.

  9. Expand coverage gradually. Recurring tasks, incidents, third-party risk, findings management — each one when there is capacity to sustain it.

Habits that keep it honest

Section titled “Habits that keep it honest”

Keep the focus on actions. Applied controls are the single place where work is real; requirements, risk scenarios and findings all point at them. When something is ambiguous, ask what an owner would actually do about it, and record that.

Prefer deprecating to deleting. A deprecated control keeps its history, evidence and requirement links, which is exactly what a future auditor asks for. A deleted one takes the traceability with it.

Turn off what you are not using. Feature flags exist so the sidebar reflects your programme rather than the product catalogue. A shorter navigation is a more used one — and modules can come back the moment you need them, with their data intact.

Set ETAs and owners, then trust the overdue flags. An action plan without dates cannot tell you anything. X-rays will find the controls missing an owner, an ETA or an effort estimate; run it periodically and fix what it reports.

Record evidence as you go. Attaching a screenshot while you are looking at the console takes seconds. Reconstructing it three months later takes an afternoon and produces weaker evidence.

Start narrow on frameworks. A credible score on a realistic scope beats a low score against everything. Implementation groups let you commit to a tier and raise it later.

Section titled “Related”