Draft. This document has not yet been reviewed by counsel and is not in force. It is published here for review only. Bracketed tokens mark facts that still have to be filled in.

Security and Vulnerability Disclosure

Effective date: [[EFFECTIVE_DATE]]

This page describes how we protect the Service, and how to report a vulnerability. It is written for customers, prospects and security researchers.

1. No certification is claimed

Seros, LLC does not hold SOC 2 Type I or Type II, ISO/IEC 27001, PCI DSS, HITRUST, or any other security certification or attestation. We do not claim compliance with any of them. If that changes, this page will say so and the report will be available under NDA.

We also do not currently offer a HIPAA Business Associate Agreement. Do not send protected health information to the Service.

Saying this plainly is deliberate. A security page that implies certifications the company does not have is a misrepresentation, and enterprise security reviewers check.

2. How the Service is built and run

The statements below must be verified against reality before this page is published. Where a control is not yet in place, delete the line or mark it as planned with a date. Do not publish an aspiration as a fact.

Architecture - Multi-tenant cloud application hosted in the United States with [[TBD_VENDOR]]. - Logical separation between tenants, enforced at the application and data layers: [[TOM_TENANT_ISOLATION]]. - Production environments are separate from development and test environments, and production data is not copied into them: [[TOM_ENV_SEPARATION]].

Encryption - TLS 1.2 or higher for all connections to the Service: [[TOM_TLS]]. - Encryption at rest for databases, object storage and backups: [[TOM_ENCRYPTION_AT_REST]]. - Secrets and keys are managed in [[TOM_KEY_MANAGEMENT]] and are not stored in source control.

Access control - Least-privilege access for staff, reviewed at least quarterly. - Multi-factor authentication required for administrative and production access: [[TOM_MFA]]. - Customer-side controls: role-based permissions, and single sign-on where supported: [[TOM_CUSTOMER_SSO]]. - Passwords are stored using a modern password hashing function: [[TOM_CREDENTIALS]].

Development - Code review before merge and automated tests in the pipeline: [[TOM_CHANGE_MANAGEMENT]]. - Dependency and vulnerability scanning: [[TOM_VULN_SCANNING]]. - Penetration testing: [[TOM_PENTEST]].

Monitoring and response - Centralised logging, alerting and retention of security logs for 12 months: [[TOM_LOGGING]]. - Documented incident response process with defined roles and a customer notification path: [[TOM_INCIDENT_RESPONSE]]. - Backups with a tested restore procedure: [[TOM_BACKUP_RPO_RTO]].

Vendors - Subprocessors are listed at SUBPROCESSORS.md, each under a written contract with data protection terms.

AI providers - Customer content sent to AI model providers is limited to what a feature needs, and our provider terms are intended to prohibit training on it. Details in AI-DISCLOSURE.md.

3. Customer responsibilities

Security is shared. You are responsible for:

• Who you invite, what role you give them, and removing people who leave.
• Protecting credentials and API keys, and rotating them if exposed.
• Enabling multi-factor authentication or single sign-on for your users.
• Deciding which systems to connect and what scope to grant.
• Not putting prohibited data into the Service (see the Acceptable Use Policy).
• Reviewing AI output before acting on it.

4. Incident notification

If we become aware of a security incident affecting your data, we will notify you without undue delay and within 72 hours, with what we know at the time, and will update you as the investigation progresses. The contractual detail is in Section 9 of the DPA.

5. Vulnerability disclosure policy

We want to hear about security problems. This section is our commitment to researchers who act in good faith.

5.1 How to report

Email security@seros.dev with:

• A description of the issue and its impact.
• Steps to reproduce, ideally with a proof of concept.
• The URLs, endpoints, accounts and timestamps involved.
• Your name or handle, if you want credit.

Encrypt if you prefer: not published; email in plain text and we will arrange an encrypted channel if needed. Use one report per issue. We will publish a /.well-known/security.txt file pointing at this policy: https://seros.dev/.well-known/security.txt.

5.2 What we commit to

These are targets, not contractual commitments, unless a signed agreement says otherwise.

5.3 Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will:

• Consider your research authorised under the Computer Fraud and Abuse Act, applicable Georgia computer crime law, and any anti-circumvention provisions of the DMCA, to the extent those laws allow us to authorise it;
• Not pursue or support civil or criminal action against you for that research;
• Waive any claim that your research breached our Terms of Service or Acceptable Use Policy; and
• If a third party brings action against you for research conducted in accordance with this policy, make it known that your activity was authorised.

This authorisation extends only to us. We cannot authorise testing of systems owned by our subprocessors or by other third parties; report those to their owners. If legal action is initiated by a third party and you complied with this policy, we will make that clear.

If you are unsure whether something is in scope, ask first at security@seros.dev.

5.4 Scope

In scope - https://seros.dev and its subdomains that we operate. - The Seros web application and public API. - Our official mobile or desktop clients, if any exist.

Out of scope - Third-party services and infrastructure we do not control, including our hosting, payment, email and AI model providers. - Denial-of-service and volumetric testing. - Social engineering of staff, customers or vendors, and physical security testing. - Automated scanning that generates significant traffic, without written permission. - Reports generated solely by an automated tool with no analysis or demonstrated impact. - Findings that are configuration opinions rather than exploitable issues: missing security headers with no demonstrated impact, SPF/DMARC policy preferences, TLS cipher preferences, version disclosure, clickjacking on pages with no sensitive action, missing rate limits with no demonstrated abuse, self-XSS, and issues requiring a rooted device, a physically present attacker or an already-compromised account.

5.5 Rules

• Only test accounts and data you own or have explicit permission to test.
• Never access, modify, exfiltrate or delete another party's data. If you encounter personal data, stop, do not save it, and tell us in the report.
• Stop as soon as you have confirmed the vulnerability.
• Do not disclose publicly until we have fixed the issue, or until 90 days after your report, whichever comes first, and coordinate the wording with us.
• Do not demand payment in exchange for withholding a report. That is extortion, not research, and the safe harbour does not apply to it.

5.6 Rewards

We do not currently operate a paid bug bounty. We will credit researchers by name or handle in an acknowledgements list at https://seros.dev/security.html#acknowledgements if they want it. Whether a bounty is introduced is no paid bounty at this stage; credit offered instead.

What I need from you

1. Delete or correct every control statement in Section 2 that is not true today.
2. Set up security@seros.dev as a monitored inbox before publishing this page.
3. Fill the response targets. Do not promise a 24-hour acknowledgement you cannot meet on a weekend.
4. Have counsel review the safe harbour wording. The intent is standard, but the CFAA and DMCA references should be checked.
5. Publish security.txt at the well-known path once the email exists.