1. Purpose

This Safety Standards document defines the technical, organizational, and procedural controls required to ensure the ERP application (“the App”) operates safely and securely. The App does not store, process, transmit, or otherwise involve CSAE (Child Sexual Abuse/Exploitation) data. This document sets out:

  • Security-by-design and privacy-by-design requirements.
  • Prohibited uses and content boundaries (explicitly excluding CSAE).
  • Operational safeguards for environments, support workflows, and third parties.
  • Monitoring, incident response, continuity, and assurance.

Note: This document is not legal advice. Jurisdiction-specific obligations should be validated with counsel.

2. Scope and Applicability

  • In scope: The App’s code, build pipelines, infrastructure, configurations, operational processes, support workflows, vendor integrations, and data processed to deliver the ERP features.
  • Out of scope: Any use of the App to store, process, transmit, or reference CSAE data. Such content is explicitly prohibited and unsupported.
  • Audience: Engineering, Product, Security, Operations, Support, Procurement, and Compliance teams; relevant suppliers.

3. Definitions

  • CSAE (Child Sexual Abuse/Exploitation) data: Any content, metadata, reference, or derivative that facilitates, depicts, or relates to sexual exploitation or abuse of minors.
  • Customer Data: Business data required to operate ERP functionality (e.g., orders, inventory, financial postings) excluding any content that violates the Acceptable Use Policy (AUP).
  • Personal Data: Data relating to an identified or identifiable individual as defined by relevant privacy laws (e.g., GDPR) when applicable to the ERP use case.
  • Sensitive Categories: Special categories of personal data under privacy law (e.g., health, biometrics). The App does not require or request such data.
  • Prohibited Content: CSAE and any illegal content, malware, or material violating the AUP.

4. Governance and Policy Framework

  • Zero‑Tolerance CSAE Exclusion:
    • The App is not designed for, and must not be used to store or process CSAE.
    • Contracts, ToS, and AUP must explicitly prohibit CSAE content or use.
    • Marketing, documentation, and onboarding communicate the exclusion and acceptable use.
  • Leadership and Accountability:
    • The Security & Compliance function owns these standards and audits conformance.
    • Product and Engineering leaders ensure SDLC compliance.
    • Vendors must contractually commit to equivalent controls.
  • Standards Alignment (non-exhaustive):
    • ISO/IEC 27001 (ISMS), ISO/IEC 27002 (controls)
    • SOC 2 (Security, Availability, Confidentiality)
    • OWASP ASVS (application control baseline)
    • NIST SP 800‑53 (security controls catalog)

5. Acceptable Use and Content Boundaries

  • Prohibited Uses:
    • Uploading, storing, processing, or referencing CSAE or any illegal content.
    • Using integrations, APIs, or custom fields to introduce prohibited content.
  • Product Guardrails:
    • Disable arbitrary file uploads unless required for ERP function; default-deny unknown file types.
    • If attachments are enabled (e.g., invoices), enforce file-type allowlists, size limits, malware scanning, and metadata stripping.
    • UI copy and admin settings must signal prohibited content and consequences.
  • Support Channels:
    • Support tickets, logs, or diagnostic uploads must follow the same prohibitions.
    • If user-provided artifacts appear to contain prohibited content, do not open or preview; follow the Escalation & Reporting Playbook (Section 11 & 12).

6. Data Classification & Minimisation

  • Data Inventory: Maintain a data flow diagram and RoPA (Record of Processing Activities) covering: data types, purpose, storage location, lawful basis (if applicable), and retention.
  • Minimisation: Collect only data essential to ERP operation; avoid special categories; never request, store, or infer CSAE-related content.
  • Segregation: Separate production, staging, and development data; prohibit production PII in lower environments unless irreversibly de-identified.

7. Secure Development Lifecycle (SSDLC)

  • Requirements & Threat Modeling: Include abuse/misuse cases; verify that features cannot be repurposed to store prohibited content.
  • Secure Coding: Follow OWASP ASVS/Top 10; enforce SAST/DAST; mandate peer reviews for security-impacting changes.
  • Secrets Management: Use a KMS/secret vault; no secrets in source control.
  • Dependency Hygiene: SBOM generation; vulnerability scanning (continuous); approved open-source licenses list.
  • Build Integrity: Signed commits, reproducible builds where feasible, CI/CD pipeline isolation, artifact signing.
  • Pre‑Release Security Gates: Security review for new data types, attachment features, or API endpoints.

8. Identity, Access, and Authentication

  • Principle of Least Privilege (PoLP) and RBAC/ABAC across application and cloud layers.
  • Strong Authentication:
    • Admin and privileged accounts: MFA mandatory.
    • Customer tenants: MFA recommended/enforced per risk profile.
  • Session Security: Modern session tokens (short-lived), secure cookies, CSRF protections, device-binding where appropriate.
  • Joiner‑Mover‑Leaver: 24-hour SLA for access changes; immediate revocation on termination.
  • Auditability: All admin actions, permission changes, and authentication events are logged and monitored.

9. Application & API Security

  • Input/Output Validation: Strict server-side validation; canonicalization; output encoding.
  • Rate Limiting & Abuse Prevention: Per-IP and per-identity throttling; bot detection for critical endpoints; anomaly flags.
  • Multitenancy Isolation: Logical isolation per tenant; no cross-tenant data access; scoped tokens.
  • Cryptography:
    • Data at rest: Strong encryption (e.g., AES‑256) for disks and databases.
    • In transit: TLS 1.2+; HSTS; modern cipher suites.
    • Key rotation policies and dual control for KMS operations.
  • File Handling (if enabled): Allowlist MIME types, AV scanning, sandboxing of document previews, content-disarm (CDR) where feasible.

10. Infrastructure & Operations Security

  • Cloud Baselines: Hardened images; CIS benchmarks where applicable; immutable infrastructure patterns.
  • Network Security: Segmented VPC/VNet; WAF; private subnets for data stores; deny-by-default security groups.
  • Patching & Vulnerability Management:
    • Patch SLAs by severity (e.g., Critical ≤7 days, High ≤14 days).
    • Continuous scanning of hosts, containers, and images.
  • Backups & Recovery: Encrypted, tested backups; defined RPO/RTO; cross-region redundancy per business needs.
  • Monitoring & Telemetry: Centralized logs, metrics, traces; time synchronization; tamper-evident storage.

11. Logging, Monitoring, and Detection

  • Coverage: Auth events, admin actions, configuration changes, data access anomalies, integration errors, file uploads (if any), and security controls state.
  • PII-Safe Telemetry: Avoid sensitive payloads in logs; tokenization where needed.
  • Alerting & Triage: On-call rotation; runbooks; automated enrichment (host/user/tenant context).
  • Prohibited Content Signals: While the App should not process CSAE, any indicators (e.g., filenames, user self-disclosure in support text) must trigger non-viewing escalation to Security for handling under Section 12. No human should open suspected illegal content.

12. Incident Response (IR)

  • IR Plan: Define roles (Incident Commander, Comms, Forensics, Legal).
  • Classification: Sev‑1 (active compromise or legal exposure), Sev‑2 (material control failure), Sev‑3 (minor).
  • Playbooks:
    • Security Breach (general)
    • Abuse/Misuse Attempt
    • Prohibited Content Indication (CSAE):
      • Do not access or preview suspected content.
      • Isolate artifacts; preserve minimal metadata required for chain-of-custody (hashes, timestamps) without viewing content.
      • Notify Legal and Leadership immediately; follow jurisdictional reporting requirements via counsel.
      • Suspend accounts involved pending investigation.
  • Post‑Incident: Root cause analysis (RCA), corrective actions, and control improvements.

13. Business Continuity & Disaster Recovery (BC/DR)

  • BCP: Defines critical processes, dependencies, and maximum tolerable downtime.
  • DR Testing: At least annually; tabletop plus failover simulations.
  • Supply Chain Resilience: Validate critical vendors’ BC/DR posture; maintain alternates where feasible.

14. Data Retention & Disposal

  • Retention Schedule: Define by data type (ERP functional data only). No retention for prohibited content.
  • Secure Disposal: Cryptographic erasure and media sanitization; verifiable deletion on customer request (where applicable).
  • Legal Hold: Process to suspend deletion for litigation/regulatory purposes via counsel.

15. Privacy and Regulatory Considerations

  • Privacy-by-Design: DPIAs (where applicable), minimal personal data processing in ERP context.
  • User Rights (if applicable): Access, rectification, deletion—subject to authentication and lawful basis.
  • International Transfers: Use approved mechanisms (e.g., SCCs) where cross-border data flows exist.

16. Third‑Party & Integration Security

  • Due Diligence: Security questionnaires, certifications (e.g., ISO 27001/SOC 2), DPAs, and AUP alignment including explicit CSAE prohibition.
  • Technical Controls: Scoped API keys, IP allowlisting, least privilege, per‑tenant secrets.
  • Continuous Assurance: Annual reassessment; termination rights for control failures or AUP violations.

17. Environment Segregation & Change Management

  • Segregation: Dev/Test/Prod separated; no shared credentials; blocked east-west paths.
  • Change Control: Ticketed changes, peer review, automated tests, security gates, and rollback plans.
  • Emergency Changes: Documented, time-bound, and retrospectively reviewed.

18. Training & Awareness

  • Mandatory Training: Annual secure coding (engineering), security & privacy (all staff), incident handling (on-call), and AUP with emphasis on CSAE prohibition.
  • Role-Based: Elevated training for SRE, Security, and Support.
  • Phishing & Social Engineering: Periodic simulations and feedback loops.

19. Assurance, Testing, and Audits

  • Penetration Testing: At least annually and after major releases; cover multi-tenant isolation and API abuse paths.
  • Controls Testing: ISMS internal audits; track findings to closure.
  • Metrics: MTTD/MTTR, patch SLAs, privileged access counts, test coverage, open vulnerabilities by severity.

20. Enforcement

  • Contractual Terms: ToS/AUP explicitly prohibit CSAE and illegal content.
  • Account Actions: Suspension/termination for violations; report to authorities as legally required through counsel.
  • Employee Conduct: Disciplinary action for policy breaches.