Home / Methodology

Methodology

How Svitsec scopes, tests, validates, and reports security work.

The aim is simple: agree what is safe to test, check the findings properly, and give you a report that stands up when engineers, leaders, or customers ask questions.

Boundaries in writingManually checkedEvidence you can use
Methodology and evidence interface
Testing starts with agreement. Targets, exclusions, access, timing, and communication are confirmed before work begins.

Boundaries agreed before testing

We agree target systems, exclusions, access, timing, communication, and report audience before testing starts.

Manually checked

Tools help find signals. Important findings are checked manually so the report reflects real exposure rather than scanner noise.

Evidence you can use

Findings show what was observed, who or what is affected, why it matters, and what should change next.

Follow-up and handoff

Reports are written so technical and non-technical teams can use the same evidence in different conversations.

Service line depth

The depth changes by service; the standard does not.

An app test, infrastructure review, posture assessment, and AI review each need different depth. The standard stays the same: agreed boundaries, manual checking, and evidence people can use.

  • Applications: authentication, authorisation, tenant boundaries, APIs, mobile trust, and workflow abuse
  • Infrastructure: exposure, remote access, cloud identity, management paths, segmentation, and reachability
  • Posture: governance, identity, resilience, reporting expectations, and uplift priorities
  • AI: data access, retrieval leakage, tool permissions, approvals, logging, and automation boundaries

References

Use frameworks when they make the work clearer.

Frameworks help when they clarify the review, not when they add paperwork. Where useful, the work can align with OWASP, cloud and identity guidance, the Essential Eight, or NIST-style controls.

Keep reporting practical.

AI review follows the same rule: prompts are only one input. Permissions, retrieval boundaries, tool access, approvals, logging, and workflow design shape what the system can do.

Working principle: keep the work specific, remove ambiguity, and leave the team with something useful.

Request a quote

Request a quote.

Tell us about the system, timeline, and decision you need to support.