Customer release scope

Customer release intent

The customer release should help a small or medium business move from uncertainty to an actionable security plan. The first release is intentionally narrow: verify an important asset, collect useful evidence, explain what matters, and turn the result into assigned work.

Initial value

The first useful experience should provide:

• A clear security workspace for one tenant
• A risk snapshot
• A prioritized action queue
• A basic control checklist
• Guided incident response notes
• Support documentation that explains product workflows as they become real

The release should be useful even if a customer only connects a small number of systems. A narrow, trusted workflow is more valuable than a broad dashboard with unclear actions.

First customer workflow

The first customer workflow should look like this:

1. Create a tenant workspace and owner account.
2. Invite the people who will approve, operate, or review security work.
3. Connect one identity, SaaS, or telemetry source.
4. Review the first posture snapshot.
5. Assign the first few risks or controls to real owners.
6. Capture notes from the first review so the product and docs improve together.

Product boundaries

Sotiras should not begin by trying to replace every existing security, monitoring, or hosting tool. The first product should connect to useful systems, normalize what matters, and guide the customer through action.

Runtime support should be used only where it makes Security as a Service easier to implement, such as on-demand scans, collectors, remediation checks, or selected workloads that benefit from built-in security controls.

The first runtime-adjacent security experiment should be proxy-first: put a Sotiras-controlled security layer in front of an existing app, prove which controls work without app changes, and identify which controls require deeper app context.

The first identity experiment should support tenant SSO for customers with an existing security framework and define how runtime apps can delegate common auth routes to Sotiras.

The customer release should avoid:

• Competing with broad hosting platforms before Security as a Service workflows are proven
• Silent high-impact remediation
• Generic alert aggregation without ownership or next steps
• Complex enterprise features before SMB workflows are validated

Early proof points

The customer release should prove that Sotiras can:

• Reduce time to the first useful risk review.
• Help a non-specialist explain why a risk matters.
• Turn evidence into assigned work.
• Keep incident notes and follow-up tasks organized.
• Integrate with at least one existing customer system or telemetry path.
• Use AI for summarization and drafting without hiding the decision trail.

What is intentionally manual

Early onboarding can be service-assisted. Sotiras should learn from setup friction before automating everything. Manual setup is acceptable when it helps validate the right workflow, permission model, and support guidance.

Practical sequence

A reasonable early sequence is:

1. Secure account access and tenant membership.
2. Model assets, risks, controls, incidents, and evidence.
3. Add tenant identity policy and one SSO proof of concept.
4. Add first integrations and local collector experiments.
5. Build the first daily review and remediation workflows.
6. Add AI summaries that are grounded in known product data.
7. Expand support docs from real onboarding and support feedback.

Feedback requested from customers

Customers should report:

• Which risks were easy or hard to understand.
• Which recommendations felt practical.
• Which setup steps required outside help.
• Which evidence sources were most useful.
• Which tasks were assigned, ignored, or deferred.
• Which support articles should be added next.