NIS2 Compliance & Information Security Policy

Sarama CRM Platform
Operator: Angad Manik Beratung fur Strategie und Projekte, Rebgasse 53, 4058 Basel, Switzerland
Responsible Person: Angad Bank (ehemals Manik), impact@angad.swiss
Platform: sarama.angad.swiss
Effective Date: 11 March 2026

1. Purpose and Scope

This Information Security Policy documents the security measures and incident response procedures of the Sarama CRM Platform in alignment with Directive (EU) 2022/2555 (NIS2 Directive), which entered into force on 16 January 2023 and requires transposition by EU member states by 17 October 2024.

Although Angad Manik Beratung fur Strategie und Projekte is a Swiss entity and not directly subject to NIS2, we adopt NIS2-aligned security practices because:

• We serve customers in the EU who may be subject to NIS2;
• NIS2 Art. 21 requires entities to secure their supply chains, including non-EU providers;
• Adopting NIS2 standards demonstrates due diligence and supports customer compliance.

This policy covers the Sarama CRM Platform and all systems, data, and processes involved in its operation.

2. Governance and Accountability

2.1 Management Responsibility (NIS2 Art. 20)

• Responsible Person: Angad Bank (ehemals Manik) (sole proprietor) is accountable for information security and approves all security policies.
• Security reviews are conducted periodically and after any significant incident or architecture change.
• This policy is reviewed and updated at least annually.

2.2 Risk Management Approach (NIS2 Art. 21(1))

We adopt a risk-based approach to security, proportionate to our size, the nature of our services, and the potential impact of incidents on our customers.

3. Risk Management Measures (NIS2 Art. 21(2))

3.1 Risk Assessment and Policies (Art. 21(2)(a))

Risk Register (key risks identified):

3.2 Incident Handling (Art. 21(2)(b))

See Section 5 (Incident Response Plan).

3.3 Business Continuity (Art. 21(2)(c))

• Database backups: Managed by Supabase (daily automated backups, point-in-time recovery for Pro plans).
• Infrastructure: Supabase Zurich region with AWS underlying infrastructure.
• Data export: Customers can request full data export at any time.
• Recovery objective: Restore service within 24 hours of a major incident.

3.4 Supply Chain Security (Art. 21(2)(d))

Sub-processors and their security posture:

Supply chain measures:

• Dependency lock files (package-lock.json) to prevent unexpected updates.
• API keys for third-party services stored with AES-256-GCM encryption.
• Customer-provided API keys — customers manage their own credentials with rotation guidance.
• OAuth tokens stored in Supabase Vault (encrypted).

3.5 Security in Development and Maintenance (Art. 21(2)(e))

• Vulnerability management: Dependencies reviewed before updates. Known CVEs tracked.
• Secure coding: Parameterised queries (via Supabase client), input sanitisation (DOMPurify), output encoding.
• Code review: All changes reviewed before deployment.
• OWASP Top 10: Addressed across the application:
  • A01 Broken Access Control → Row-Level Security (RLS) on all tables
  • A02 Cryptographic Failures → AES-256-GCM, TLS 1.2+
  • A03 Injection → Parameterised queries, no raw SQL from user input
  • A05 Security Misconfiguration → CSP headers, no CORS wildcard
  • A07 XSS → DOMPurify for HTML rendering
  • A09 Logging → Audit log for all data operations

3.6 Effectiveness Assessment (Art. 21(2)(f))

• Security measures are assessed after each significant change or incident.
• Penetration testing and red team exercises are conducted periodically.
• Findings are documented and remediated with tracked timelines.

3.7 Cybersecurity Training (Art. 21(2)(g))

• The responsible person maintains current knowledge of cybersecurity threats and best practices.
• Security awareness is integrated into operational procedures.

3.8 Cryptography (Art. 21(2)(h))

3.9 Access Control and Asset Management (Art. 21(2)(i))

Authentication:

• OTP-only (email one-time password) — no stored passwords.
• No password reuse, phishing, or brute-force risk.

Authorisation:

• Organisation-level isolation via Row-Level Security.
• Role-based access within organisations (Owner, Admin, Member roles).
• Account-level roles (Owner, SDR, AE, CSM, SE, Member) with granular permissions.
• Membership changes only via RPCs (INSERT policy: WITH CHECK (false)).
• AI agents and automations act only within the user’s own organisation and inherit that user’s permissions — they cannot access other organisations’ data, encrypted credentials, or platform internals.

API Key Management:

• Customer API keys encrypted at rest.
• Recommended rotation: every 90 days.
• Immediate rotation mandated after any security incident.
• Platform secrets (UNSUBSCRIBE_SECRET, ENCRYPTION_KEY) — no fallback values, must be configured.

3.10 Multi-Factor Authentication (Art. 21(2)(j))

• Current: OTP-based authentication provides a single strong factor (possession of email account).
• MFA via TOTP or hardware keys is on the roadmap for enhanced security.

3.11 AI Agents and Automated Actions

• AI agents operate strictly within a single organisation; the same isolation that separates customers applies to every agent action.
• Agents that read or edit content are limited to the content the user authorises and to that user’s role permissions; all changes pass through permission-checked, audited server functions.
• Customer-provided AI provider keys are never exposed to AI models, to agents, or to other customers — they remain encrypted at rest and are used only to make that customer’s own provider calls.
• Agents cannot issue arbitrary database queries or reach platform internals; they may only invoke a fixed, validated set of content actions.

4. Public Endpoint Security

The Platform exposes public (unauthenticated) endpoints for forms and email tracking:

Rate limiting prevents abuse of all public endpoints. Responses do not leak internal identifiers.

5. Incident Response Plan (NIS2 Art. 21(2)(b), Art. 23)

5.1 Incident Classification

5.2 Incident Response Steps

1. Detection & Triage (0–1 hour) — Identify scope, affected data, and affected customers. Classify severity per table above.
2. Containment (1–4 hours) — Isolate affected systems or accounts. Revoke compromised credentials. Disable affected endpoints if necessary.
3. Notification (within 24 hours for significant incidents) — Notify affected customers via email. For data breaches: notify within 72 hours per GDPR Art. 33. For NIS2-significant incidents: notify relevant CSIRT within 24 hours (early warning), full report within 72 hours.
4. Eradication & Recovery (1–7 days) — Root cause analysis. Patch vulnerabilities. Restore from backups if necessary. Mandate API key rotation for affected customers.
5. Post-Incident Review (within 30 days) — Document lessons learned. Update risk register. Implement preventive measures. Update this policy if needed.

5.3 NIS2 Reporting Timeline (Art. 23)

5.4 Customer Notification Template

In the event of a security incident affecting customer data, we will communicate:

• Nature of the incident
• Categories and approximate number of affected records
• Likely consequences
• Measures taken or proposed
• Recommendation to rotate all API keys immediately
• Contact point for further information

6. API Key and Credential Security

6.1 Platform-Managed Secrets

6.2 Customer-Managed Credentials

6.3 Breach Scenario: Key Rotation Protocol

If a breach is suspected or confirmed:

1. All affected customer API keys are immediately invalidated server-side (where technically possible).
2. Customers are notified to regenerate keys at the provider (Anthropic, OpenAI, Google).
3. New keys must be re-entered in the Platform.
4. OAuth integrations: customers are advised to revoke and re-authorise.
5. Platform secrets are rotated by the operator.

7. Data Isolation and Multi-Tenancy

• Every database table enforces Row-Level Security (RLS) scoped to organization_id.
• No cross-organisation data access is possible through the application layer.
• Database queries are executed through the Supabase client with schema('crm') — no raw SQL from user input.
• Membership INSERT is blocked (WITH CHECK (false)) — all membership changes via controlled RPCs.
• Edge functions validate auth.uid() + organisation membership before any data access.

8. Logging and Monitoring

9. Compliance Mapping

10. Review and Updates

This policy is reviewed:

• At least annually;
• After any significant security incident;
• After major architecture changes;
• When NIS2 national transposition laws are updated.

11. Contact

For security enquiries or to report a vulnerability:

Angad Manik Beratung fur Strategie und Projekte
Angad Bank (ehemals Manik)
Rebgasse 53, 4058 Basel, Switzerland
Email: impact@angad.swiss

For urgent security incidents, email with subject line: [SECURITY INCIDENT] — Sarama CRM

Last updated: 28 March 2026