Security scope
The asset classes and security timeline Sotiras uses to organize protection work. Start here if you already know the procedure, or go back to the support docs index if you need a different topic.
I want this article
Read the current support note if you are already in the right procedure.
I want the docs index
Go back to the section list when you need a different article or category.
I want support context
Jump to support docs home when the question is broader than one article.
Markdown article
Source: content/support-docs/security-operations/security-scope.md
What Sotiras helps secure
Sotiras starts with the practical question: what are we securing?
The first asset classes are:
| Asset class | Examples | Why it matters |
|---|---|---|
| Servers | Linux hosts, cloud instances, database hosts, PBX servers | Often expose admin ports, logs, services, and high-impact workloads. |
| Applications | Public sites, customer portals, admin apps, APIs | Carry business logic, user access, and customer data exposure. |
| Endpoints and devices | Laptops, desktops, mobile devices, shared workstations | Common entry points for phishing, malware, and credential compromise. |
| Identity systems | Local accounts, SSO, MFA, privileged accounts | Control access across the business. |
| SaaS platforms | Email, productivity suites, CRMs, finance tools, ticketing | Hold business data and permissions outside local infrastructure. |
| Networks | Firewalls, VPNs, DNS, ingress, cloud networks | Shape exposure, segmentation, and remote access. |
| Data | Customer records, backups, regulated data, exports | Determines business impact and recovery obligations. |
| Vendors | MSPs, contractors, SaaS vendors, service providers | Extend access and operational responsibility beyond the company. |
Every finding, alert, control, risk, and incident should connect back to one or more assets so the customer can understand ownership and impact.
Security timeline
Sotiras organizes security work across the full timeline:
| Stage | Product focus |
|---|---|
| Prevent | Audits, posture checks, control coverage, and hardening recommendations |
| Detect | Monitoring, integrations, collectors, findings, and evidence intake |
| Respond | Triage, incident workspace, ownership, containment, and communication |
| Recover | Follow-up tasks, control improvements, restore validation, and lessons learned |
| Preserve | Evidence handling, source references, audit trail, and forensic support when impact requires deeper review |
For many SMB incidents, the goal is practical clarity and recovery. Deeper forensic handling matters when an incident may involve data exposure, fraud, ransomware, privileged account takeover, regulatory obligations, insurance review, legal sensitivity, or major business interruption.
How to prioritize scope
Start with the systems that affect business continuity and account takeover risk:
- Identity, email, and privileged access.
- Backup readiness and recovery paths.
- Internet-facing applications, servers, and remote access.
- Core SaaS systems and vendors with sensitive data.
- Endpoint posture and device hygiene.
Do not try to perfect every asset class before creating useful work. The first goal is credible visibility and ownership.
Where AI assists
AI should help explain, summarize, prioritize, draft, and recommend. It should not silently make high-impact security changes.
Useful AI assistance includes:
- Plain-language summaries for non-specialists
- Risk explanations tied to business impact
- Draft remediation plans
- Incident notes and stakeholder updates
- Evidence summaries with clear source references
- Recovery checklists and missing-evidence prompts
Approval boundary
High-impact remediation must require human approval, tenant policy checks, and audit logging. The product should be helpful without becoming an unreviewed automation engine.
Examples of high-impact actions include disabling a user account, changing firewall access, blocking a source across open ports, revoking vendor access, deleting data, or changing backup and recovery settings.
Evidence boundary
Sotiras should prefer normalized metadata for routine review and preserve raw evidence only when it is useful, safe, and policy-approved. Logs, payloads, and incident artifacts can contain sensitive data, tokens, secrets, or customer information.