|
|
|
|
@@ -0,0 +1,720 @@
|
|
|
|
|
## Does your organisation have an approved information security policy?
|
|
|
|
|
|
|
|
|
|
No, we do not currently have a formal information security policy document. As a small startup with 2 employees, we have chosen to focus on implementing practical security controls rather than formal documentation at this stage.
|
|
|
|
|
However, we do maintain several key security practices:
|
|
|
|
|
Product Security (Evie SaaS Platform):
|
|
|
|
|
|
|
|
|
|
Multi-tenant architecture with strict data isolation (separate database schemas and object storage folders per tenant)
|
|
|
|
|
Hosted exclusively with European providers (Scaleway, Bunny.net, Mistral) compliant with EU regulations
|
|
|
|
|
Published Privacy Policy and Terms & Conditions
|
|
|
|
|
GDPR-compliant data handling practices
|
|
|
|
|
|
|
|
|
|
Internal Operations Security:
|
|
|
|
|
|
|
|
|
|
Secure password and credential management using Proton Pass
|
|
|
|
|
All internal business data maintained in secure cloud environments (Proton, Dropbox, Canva)
|
|
|
|
|
Code versioning and backup through GitHub
|
|
|
|
|
Controlled access to all systems and services
|
|
|
|
|
|
|
|
|
|
We plan to formalise our security practices into a comprehensive security policy as our organisation scales beyond 10 employees.
|
|
|
|
|
|
|
|
|
|
## Does your organisation conduct Pre Employment Checks?
|
|
|
|
|
|
|
|
|
|
No, we do not currently conduct formal pre-employment checks. Our current team consists of 2 employees in a family business structure, where trust and accountability are inherent to the relationship.
|
|
|
|
|
However, we recognize the importance of vetting as we scale. For future hires, we will implement the following practices:
|
|
|
|
|
Planned Hiring Procedures:
|
|
|
|
|
|
|
|
|
|
- In-depth personal interviews conducted by the founder
|
|
|
|
|
- Professional reference checks with former colleagues and employers
|
|
|
|
|
- Review of professional background and experience
|
|
|
|
|
|
|
|
|
|
Access Control for New Hires:
|
|
|
|
|
|
|
|
|
|
- New employees will not have immediate access to production systems or customer data
|
|
|
|
|
- Onboarding will begin with development and test environments using internally-created synthetic data
|
|
|
|
|
- Access to production systems will only be granted after thorough training and demonstration of competency with our platform
|
|
|
|
|
|
|
|
|
|
We anticipate hiring 2-3 additional resources once we secure appropriate investment, at which point these procedures will be formalized and documented.
|
|
|
|
|
|
|
|
|
|
## Does your organisation have an information security awareness program that provides training for all its employees/contractors?
|
|
|
|
|
|
|
|
|
|
No, we do not currently have a formal information security awareness training program. As a 2-person team, security awareness is maintained through the founder's 30+ years of IT and application development experience, including hands-on security implementation.
|
|
|
|
|
However, we maintain ongoing security awareness through several practices:
|
|
|
|
|
Current Security Practices:
|
|
|
|
|
|
|
|
|
|
- Active monitoring of security updates and advisories from our infrastructure providers (Scaleway, Bunny.net, Mistral)
|
|
|
|
|
- Proactive system updates and patching in response to security notifications
|
|
|
|
|
- Implementation of industry best practices (e.g., Kubernetes security configurations)
|
|
|
|
|
- Regular review and updates of security measures as the threat landscape evolves
|
|
|
|
|
- Security-conscious architecture decisions (e.g., Bunny.net as additional security layer in front of our K8s cluster)
|
|
|
|
|
|
|
|
|
|
Planned Training for Future Hires:
|
|
|
|
|
|
|
|
|
|
- Structured onboarding covering our security practices and data handling procedures
|
|
|
|
|
- Training on secure credential management (Proton Pass usage)
|
|
|
|
|
- Introduction to our multi-tenant architecture and data isolation principles
|
|
|
|
|
- Access control procedures and least-privilege principles
|
|
|
|
|
|
|
|
|
|
As we scale and onboard additional resources, we will implement enhanced security controls (NPM hardening, role-based access in PgAdmin, etc.) and formalize our security awareness program with documented training materials and periodic refresher sessions.
|
|
|
|
|
|
|
|
|
|
## Does your organisation have a policy for ensuring that Customer information is protected?
|
|
|
|
|
|
|
|
|
|
No, we do not currently have a formal customer information protection policy document. As a small startup with 2 employees, we have chosen to focus on implementing practical technical and operational controls rather than formal documentation at this stage.
|
|
|
|
|
However, we maintain comprehensive protection measures for customer data:
|
|
|
|
|
Technical Protections:
|
|
|
|
|
|
|
|
|
|
- Multi-tenant architecture with strict data isolation (separate database schemas and object storage folders per tenant)
|
|
|
|
|
- Password hashing (no plain text storage)
|
|
|
|
|
- Encryption in transit across all layers (browser → Bunny.net CDN → Kubernetes cluster)
|
|
|
|
|
- TLS encryption for internal services (Redis, PostgreSQL)
|
|
|
|
|
- Managed database and storage services with automated backup procedures
|
|
|
|
|
- Limited superuser access in production environments
|
|
|
|
|
|
|
|
|
|
Access Controls:
|
|
|
|
|
|
|
|
|
|
- Production customer data access restricted to founder only
|
|
|
|
|
- Customer-controlled partner access model (customers can grant/revoke partner access as needed)
|
|
|
|
|
- Change tracking showing who modified data
|
|
|
|
|
- Secure data deletion process (removal of database schema and object storage folder)
|
|
|
|
|
|
|
|
|
|
Data Sharing & Processing:
|
|
|
|
|
|
|
|
|
|
- Third-party data sharing limited to operationally necessary information only (billing, support)
|
|
|
|
|
- Data Processing Agreement included in our Privacy Statement
|
|
|
|
|
- Privacy Statement and Terms & Conditions are interlinked and published
|
|
|
|
|
|
|
|
|
|
Infrastructure:
|
|
|
|
|
|
|
|
|
|
- Hosted exclusively with European providers (Scaleway, Bunny.net, Mistral) compliant with EU regulations
|
|
|
|
|
GDPR-compliant data handling practices
|
|
|
|
|
|
|
|
|
|
We plan to formalise these protections into a comprehensive customer data protection policy, including encryption at rest, formal data retention policies, and incident response procedures, as our organization scales.
|
|
|
|
|
|
|
|
|
|
## Does your organisation have a procedure to manage the access rights of user accounts?
|
|
|
|
|
|
|
|
|
|
No, we do not currently have a formal documented procedure for managing access rights. However, we maintain practical access control measures appropriate to our current scale and structure.
|
|
|
|
|
Internal Access Management:
|
|
|
|
|
|
|
|
|
|
- Founder maintains sole authority for granting access to systems and environments
|
|
|
|
|
- Production superuser access restricted to founder only
|
|
|
|
|
- Access granted on a need-to-know and need-to-have basis
|
|
|
|
|
- Planned role-based access for future hires (e.g., operations staff access to infrastructure, developers limited to dev/test environments with no production access)
|
|
|
|
|
|
|
|
|
|
Customer/Tenant Access Management:
|
|
|
|
|
|
|
|
|
|
- Customers have self-service user account creation and management within their tenant
|
|
|
|
|
- Role-based access control implemented in the platform
|
|
|
|
|
- Customers manage their own users' permissions and roles
|
|
|
|
|
- User accounts can be disabled to revoke platform access
|
|
|
|
|
|
|
|
|
|
Partner Access Management:
|
|
|
|
|
|
|
|
|
|
- Partners granted access only to their specific customers' tenants
|
|
|
|
|
- Partner access provided for implementation and troubleshooting support
|
|
|
|
|
- Founder can revoke partner access as needed
|
|
|
|
|
- Access controlled through customer-partner agreements
|
|
|
|
|
|
|
|
|
|
As we scale and onboard additional employees, we will formalise access management procedures including:
|
|
|
|
|
|
|
|
|
|
- Documented approval workflows
|
|
|
|
|
- Periodic access reviews
|
|
|
|
|
- Formalized offboarding procedures for partners and employees
|
|
|
|
|
- Enhanced audit logging of access changes
|
|
|
|
|
|
|
|
|
|
## Does your organisation enforce a strong password criteria (e.g. password length, complexity) for all user/system accounts?
|
|
|
|
|
|
|
|
|
|
Yes, we enforce strong password criteria for internal systems and accounts, with planned implementation for customer accounts.
|
|
|
|
|
Internal Systems & Accounts:
|
|
|
|
|
|
|
|
|
|
- All passwords generated using Proton Pass password manager with strong complexity
|
|
|
|
|
- Secure password storage and management across all internal systems
|
|
|
|
|
- Multi-factor authentication (MFA) enabled on critical infrastructure systems (EuroDNS, Bunny.net, Scaleway)
|
|
|
|
|
- Operational passwords (databases, Kubernetes secrets) generated via Proton Pass and stored securely in cluster secrets
|
|
|
|
|
- Password changes implemented on a risk-based approach (when compromised or when security context requires), following NIST SP 800-63B guidelines
|
|
|
|
|
|
|
|
|
|
Customer Accounts in Evie:
|
|
|
|
|
|
|
|
|
|
- Strong password enforcement is planned for implementation in an upcoming release
|
|
|
|
|
- This will include minimum password length and complexity requirements
|
|
|
|
|
- Multi-factor authentication support is on our product roadmap
|
|
|
|
|
|
|
|
|
|
Planned Enhancements:
|
|
|
|
|
|
|
|
|
|
- Formal password rotation policy for system accounts
|
|
|
|
|
- MFA implementation for customer accounts
|
|
|
|
|
- Enhanced password strength requirements in the platform
|
|
|
|
|
|
|
|
|
|
## Does your organisation ensure that all systems are securely configured (hardened).
|
|
|
|
|
|
|
|
|
|
Yes, we ensure our systems are securely configured and hardened appropriate to our current scale and operational needs.
|
|
|
|
|
Production Infrastructure Hardening:
|
|
|
|
|
|
|
|
|
|
- Kubernetes cluster deployed in private network (Scaleway VPC)
|
|
|
|
|
- External access exclusively through Bunny.net Shield (WAF, advanced rate limiting, DDoS mitigation)
|
|
|
|
|
- Access to Scaleway resources controlled via IAM with API passwords
|
|
|
|
|
- Internal resource access through Kubernetes secrets
|
|
|
|
|
- Administrative access via secure port-forwarding only (no direct external external exposure)
|
|
|
|
|
- TLS encryption for all internal services (PostgreSQL, Redis)
|
|
|
|
|
- Automated infrastructure updates through Scaleway's managed services
|
|
|
|
|
|
|
|
|
|
Application Security:
|
|
|
|
|
|
|
|
|
|
- Security headers implemented
|
|
|
|
|
- Standard Flask security frameworks in place
|
|
|
|
|
- Client-side DOM inspection for XSS prevention
|
|
|
|
|
- Input validation and SQL injection prevention
|
|
|
|
|
- Regular updates of Python package dependencies for security patches
|
|
|
|
|
|
|
|
|
|
Network Segmentation:
|
|
|
|
|
|
|
|
|
|
- Production environment isolated in private network
|
|
|
|
|
- Default Scaleway firewall protections applied
|
|
|
|
|
- Administrative access restricted and controlled
|
|
|
|
|
|
|
|
|
|
Monitoring & Observability:
|
|
|
|
|
|
|
|
|
|
- Business event monitoring (Prometheus, Grafana)
|
|
|
|
|
- System monitoring through Scaleway Cockpit
|
|
|
|
|
- Internal tools (PgAdmin, RedisInsight, Flower) accessible only within controlled environments
|
|
|
|
|
|
|
|
|
|
Planned Enhancements as We Scale:
|
|
|
|
|
|
|
|
|
|
- Formal vulnerability assessments and security scanning
|
|
|
|
|
- Hardening of internal tooling access (NPM with additional access controls, role-based access in PgAdmin)
|
|
|
|
|
- Automated security testing in CI/CD pipeline
|
|
|
|
|
- Regular penetration testing
|
|
|
|
|
|
|
|
|
|
We actively maintain and update container images, system components, and application dependencies.
|
|
|
|
|
|
|
|
|
|
## Does your organisation only use licensed and supported software/applications
|
|
|
|
|
|
|
|
|
|
Yes, we exclusively use licensed and supported software and applications across our organisation.
|
|
|
|
|
Commercial Software & Services:
|
|
|
|
|
|
|
|
|
|
- All commercial tools and services are properly licensed (business or individual licenses as appropriate)
|
|
|
|
|
- Cloud infrastructure: Scaleway, Bunny.net, GitHub
|
|
|
|
|
- AI services: Mistral, OpenAI, Anthropic, Midjourney through paid plans (no free tier)
|
|
|
|
|
- Business tools: Proton (email, password management), Dropbox, Canva
|
|
|
|
|
- Development tools: PyCharm IDE
|
|
|
|
|
- Operating systems: macOS, Linux (supported distributions)
|
|
|
|
|
|
|
|
|
|
Open Source Software:
|
|
|
|
|
|
|
|
|
|
- We utilise industry-standard open source frameworks and tools (Flask, Kubernetes, Linux components, and associated libraries)
|
|
|
|
|
- We actively track releases and updates for all open source components
|
|
|
|
|
- Regular updates applied to maintain security and stability
|
|
|
|
|
- All open source software used in compliance with respective license terms
|
|
|
|
|
|
|
|
|
|
Software Management:
|
|
|
|
|
|
|
|
|
|
- Active monitoring of software updates and security patches
|
|
|
|
|
- Regular dependency updates for application components
|
|
|
|
|
- Use of supported and maintained versions of all software
|
|
|
|
|
|
|
|
|
|
We maintain awareness of licensing obligations and ensure compliance across both commercial and open source software usage.
|
|
|
|
|
|
|
|
|
|
## Does your organisation deploy an anti-virus and anti-malware management solution on all servers and client devices.
|
|
|
|
|
|
|
|
|
|
Our approach to anti-virus and anti-malware protection is adapted to our cloud-native, containerised architecture and the nature of modern security threats.
|
|
|
|
|
Production Environment:
|
|
|
|
|
|
|
|
|
|
- Cloud-native architecture running containerised workloads on Kubernetes (Scaleway)
|
|
|
|
|
- Traditional server-based antivirus is not applicable to our containerised infrastructure
|
|
|
|
|
- Infrastructure hosted on ISO/IEC 27001:2022 certified cloud provider (Scaleway) with continuous security monitoring
|
|
|
|
|
- Planned implementation of Harbor container registry with integrated vulnerability scanning for container images
|
|
|
|
|
- Multi-layered security approach including WAF, DDoS protection, and network isolation provides protection against malicious traffic
|
|
|
|
|
|
|
|
|
|
Client Devices (macOS):
|
|
|
|
|
|
|
|
|
|
- CleanMyMac X deployed with malware removal capabilities, used regularly
|
|
|
|
|
- macOS built-in security features enabled (XProtect, Gatekeeper, FileVault)
|
|
|
|
|
- Regular software updates and security patches applied
|
|
|
|
|
|
|
|
|
|
Email Security:
|
|
|
|
|
|
|
|
|
|
- Proton Mail Business with integrated spam and malware filtering
|
|
|
|
|
- Proton Sentinel enabled for advanced threat protection
|
|
|
|
|
|
|
|
|
|
Security Philosophy:
|
|
|
|
|
For modern cloud-native applications, security is achieved through:
|
|
|
|
|
|
|
|
|
|
- Immutable infrastructure and containerization
|
|
|
|
|
- Network segmentation and access controls
|
|
|
|
|
- Regular container image updates and dependency patching
|
|
|
|
|
- Web application firewall and DDoS protection
|
|
|
|
|
- Secure development practices
|
|
|
|
|
|
|
|
|
|
We recognise that cloud-native security requires a different approach than traditional antivirus solutions, focusing on container security, vulnerability management, and defense-in-depth strategies.
|
|
|
|
|
|
|
|
|
|
## Does your organisation maintain a patching program?
|
|
|
|
|
|
|
|
|
|
Yes, we maintain an active patching programme appropriate to our cloud-native infrastructure and operational scale.
|
|
|
|
|
Infrastructure Patching:
|
|
|
|
|
|
|
|
|
|
- Managed services (Kubernetes Kapsule, PostgreSQL, Redis) automatically patched by Scaleway
|
|
|
|
|
- Kubernetes cluster platform updates managed by Scaleway
|
|
|
|
|
- Internal cluster components patched by our team
|
|
|
|
|
- Critical security patches applied as soon as possible upon notification
|
|
|
|
|
- Regular security update notifications from infrastructure providers actively monitored
|
|
|
|
|
|
|
|
|
|
Application & Dependency Patching:
|
|
|
|
|
|
|
|
|
|
- Quarterly review and update cycle for Python dependencies
|
|
|
|
|
- Weekly to monthly container image rebuilds using latest available base images
|
|
|
|
|
- Regular deployment cycle ensures current security patches are in production
|
|
|
|
|
- All updates tested in dedicated test (Podman) and staging (Kubernetes) environments before production deployment
|
|
|
|
|
|
|
|
|
|
Client System Patching:
|
|
|
|
|
|
|
|
|
|
- macOS and Linux systems regularly updated with latest security patches
|
|
|
|
|
- Development tools (PyCharm) updated immediately upon release
|
|
|
|
|
- Supporting software (CleanMyMac) configured for automatic updates
|
|
|
|
|
|
|
|
|
|
Planned Enhancements:
|
|
|
|
|
|
|
|
|
|
- Implementation of automated security advisory monitoring for dependencies
|
|
|
|
|
- Container vulnerability scanning through planned Harbor registry deployment
|
|
|
|
|
- Formalised patch prioritisation process based on severity ratings
|
|
|
|
|
|
|
|
|
|
Our patching approach balances the need for security with operational stability through testing in non-production environments before deployment.
|
|
|
|
|
|
|
|
|
|
## Does your organisation have a procedure to control changes to systems?
|
|
|
|
|
|
|
|
|
|
Yes, we have established procedures to control changes to our systems, appropriate to our current scale and operational needs.
|
|
|
|
|
Change Management Process:
|
|
|
|
|
|
|
|
|
|
- Changes managed through YouTrack issue tracking system
|
|
|
|
|
- Kanban board used to track progress and status of changes
|
|
|
|
|
- Changes discussed and communicated with customers as appropriate
|
|
|
|
|
- Release cycles managed based on change type (emergency fix, bugfix, features) with preference for short deployment cycles
|
|
|
|
|
|
|
|
|
|
Version Control & Release Management:
|
|
|
|
|
|
|
|
|
|
- GitFlow workflow implemented for all code changes
|
|
|
|
|
- GitHub-based version control with branch management
|
|
|
|
|
- Official releases tagged in container registry
|
|
|
|
|
- Rollback capability maintained for all deployments
|
|
|
|
|
- Documented changelog viewable within the application
|
|
|
|
|
|
|
|
|
|
Deployment Process:
|
|
|
|
|
|
|
|
|
|
- Standard deployment path: Development → Test (Podman) → Staging (Kubernetes) → Production
|
|
|
|
|
- Production deployments restricted to authorised personnel with appropriate access rights
|
|
|
|
|
- Deployment scripts used for consistent, repeatable deployments
|
|
|
|
|
- Release guide documentation maintained
|
|
|
|
|
|
|
|
|
|
Change Types:
|
|
|
|
|
|
|
|
|
|
- Standard changes follow full development and testing cycle
|
|
|
|
|
- Emergency changes (critical security patches, major bugs) can be fast-tracked whilst maintaining appropriate testing and documentation
|
|
|
|
|
|
|
|
|
|
Planned Enhancements:
|
|
|
|
|
|
|
|
|
|
- Formalisation of deployment windows and maintenance schedules as customer base grows
|
|
|
|
|
- Expansion of authorised deployment personnel with appropriate training
|
|
|
|
|
- Enhanced change approval workflow for larger team structure
|
|
|
|
|
|
|
|
|
|
Our change control approach ensures stability and traceability whilst maintaining the agility needed for responsive software development.
|
|
|
|
|
|
|
|
|
|
## Does your organisation have a web filtering control in place (URL/reputation/category/content filtering)?
|
|
|
|
|
|
|
|
|
|
No, we do not currently have formal web filtering controls in place for employee internet access. As a 2-person startup, we have focused our security investments on protecting our production infrastructure and customer data.
|
|
|
|
|
Current Protections:
|
|
|
|
|
Network Level:
|
|
|
|
|
|
|
|
|
|
- UniFi Dream Machine Pro enterprise-grade router/firewall in place
|
|
|
|
|
- Network segmentation between company and production environments
|
|
|
|
|
|
|
|
|
|
Endpoint Level:
|
|
|
|
|
|
|
|
|
|
- Modern browser built-in phishing and malware protection (Safari, Chrome) enabled by default
|
|
|
|
|
- macOS built-in security features (XProtect, Gatekeeper) providing baseline protection against known threats
|
|
|
|
|
|
|
|
|
|
Application Level (Inbound Protection):
|
|
|
|
|
|
|
|
|
|
- Bunny.net Shield provides web application firewall, DDoS protection, and malicious traffic filtering for our production platform
|
|
|
|
|
- Multi-layered security approach protecting customer-facing systems
|
|
|
|
|
|
|
|
|
|
Planned Enhancements as We Scale:
|
|
|
|
|
|
|
|
|
|
- Implementation of DNS-based web filtering solution
|
|
|
|
|
- Enhanced threat management features on network infrastructure
|
|
|
|
|
- Input validation and URL/file scanning for customer-submitted content in the application
|
|
|
|
|
- Formalised acceptable use policies for internet access
|
|
|
|
|
|
|
|
|
|
We recognise that corporate web filtering becomes increasingly important as organisations grow and will implement appropriate controls as we expand our team beyond the current 2 employees.
|
|
|
|
|
|
|
|
|
|
## Does your organisation have a email filtering control in place (SPAM/reputation/content filtering)?
|
|
|
|
|
|
|
|
|
|
Yes, we have robust email filtering controls in place through our Proton Mail Business subscription.
|
|
|
|
|
Email Security Features:
|
|
|
|
|
Advanced Spam and Phishing Protection:
|
|
|
|
|
|
|
|
|
|
- Proton's custom spam filtering system, which is at least 60% more accurate than popular systems like SpamAssassin and catches millions of dangerous phishing emails every month The Proton Sentinel high-security program | Proton
|
|
|
|
|
- PhishGuard protection to defend against phishing attacks and spoofed email addresses
|
|
|
|
|
- Link protection feature that displays full URLs before opening to prevent malicious link clicks
|
|
|
|
|
- Automatic filtering of malicious content and attachments
|
|
|
|
|
|
|
|
|
|
Proton Sentinel Advanced Security:
|
|
|
|
|
|
|
|
|
|
- 24/7 monitoring by security analysts who review suspicious events using a combination of AI and human expertise The Proton Sentinel high-security program | Proton
|
|
|
|
|
- Advanced protection that detects and challenges suspicious login attempts and account takeover attempts The Proton Sentinel high-security program | Proton
|
|
|
|
|
- Enhanced account security logs with detailed login information
|
|
|
|
|
- Protection against social engineering attacks
|
|
|
|
|
|
|
|
|
|
Email Authentication:
|
|
|
|
|
|
|
|
|
|
- SPF (Sender Policy Framework) configured to prevent email spoofing
|
|
|
|
|
- DKIM (DomainKeys Identified Mail) configured to ensure message integrity
|
|
|
|
|
- DMARC (Domain-based Message Authentication, Reporting, and Conformance) configured to prevent abuse
|
|
|
|
|
- All authentication protocols verified and active for both askeveal.com and flow-it.net domains
|
|
|
|
|
|
|
|
|
|
Additional Protections:
|
|
|
|
|
|
|
|
|
|
- End-to-end encryption for emails between Proton Mail accounts
|
|
|
|
|
- TLS encryption for emails to external recipients
|
|
|
|
|
- Two-factor authentication (2FA) available for all accounts
|
|
|
|
|
|
|
|
|
|
Our email security infrastructure provides enterprise-grade protection against spam, phishing, malware, and account compromise attempts.
|
|
|
|
|
|
|
|
|
|
## Does your organisation have mechanisms for managing information security incidents that include reporting, detection, resolution, and recovery?
|
|
|
|
|
|
|
|
|
|
No, we do not currently have a formal documented incident response procedure. However, we have established capabilities and practices that form the foundation for incident management.
|
|
|
|
|
Detection Capabilities:
|
|
|
|
|
|
|
|
|
|
- Comprehensive monitoring infrastructure in place (Prometheus, Grafana, Scaleway Cockpit)
|
|
|
|
|
- Extensive backend logging for investigation and root cause analysis
|
|
|
|
|
- Ability to detect anomalies in system usage and performance
|
|
|
|
|
- Planned implementation of automated alerting as we scale
|
|
|
|
|
|
|
|
|
|
Reporting Mechanisms:
|
|
|
|
|
|
|
|
|
|
- Customer and partner security issue reporting through established helpdesk channels
|
|
|
|
|
- Tiered support structure (partners handle first and second line, we provide third line support)
|
|
|
|
|
- Clear escalation path for security-related issues
|
|
|
|
|
|
|
|
|
|
Response & Resolution Capabilities:
|
|
|
|
|
|
|
|
|
|
- Root cause analysis capabilities using system logs and monitoring data
|
|
|
|
|
- Ability to patch and deploy fixes rapidly through our CI/CD pipeline
|
|
|
|
|
- Access to third-party infrastructure support (Scaleway) for infrastructure-level incidents
|
|
|
|
|
- Version control allowing rollback to previous stable versions
|
|
|
|
|
- Regular backup procedures for all critical systems (databases, object storage)
|
|
|
|
|
|
|
|
|
|
Recovery Capabilities:
|
|
|
|
|
|
|
|
|
|
- Managed backup services for PostgreSQL, Redis, and Object Storage
|
|
|
|
|
- Container rollback capabilities through versioned registry
|
|
|
|
|
- Ability to restore services from backups
|
|
|
|
|
- Disaster recovery supported by cloud infrastructure redundancy
|
|
|
|
|
|
|
|
|
|
Communication:
|
|
|
|
|
|
|
|
|
|
- Commitment to immediate notification of affected customers and partners
|
|
|
|
|
- Understanding of GDPR breach notification requirements (72-hour reporting to supervisory authority)
|
|
|
|
|
|
|
|
|
|
Planned Formalisation:
|
|
|
|
|
As we scale, we will develop and document a comprehensive incident response plan including:
|
|
|
|
|
|
|
|
|
|
Formal incident classification and escalation procedures
|
|
|
|
|
- Automated alerting and monitoring rules
|
|
|
|
|
- Documented communication templates and timelines
|
|
|
|
|
- Detailed recovery procedures and runbooks
|
|
|
|
|
- Regular incident response training and tabletop exercises
|
|
|
|
|
- Contact information for relevant authorities and third-party support
|
|
|
|
|
|
|
|
|
|
Whilst we don't currently have a formal documented process, our technical capabilities and operational practices provide the essential elements needed to detect, respond to, and recover from security incidents.
|
|
|
|
|
|
|
|
|
|
## Has you organisation had a reportable information security incident in the last three (3) years
|
|
|
|
|
|
|
|
|
|
No, we have not had any reportable information security incidents in the last three years.
|
|
|
|
|
Our organisation is newly operational, having just entered production with our first customers. We have not experienced any security breaches, data leaks, unauthorised access, or other security incidents that would require reporting under GDPR or other regulatory frameworks.
|
|
|
|
|
|
|
|
|
|
## Does the provided system/service use a certified Cloud Service Provider?
|
|
|
|
|
|
|
|
|
|
Yes, our entire infrastructure is hosted exclusively on certified cloud service providers, chosen specifically for their strong security certifications and European compliance.
|
|
|
|
|
Primary Cloud Providers & Certifications:
|
|
|
|
|
Scaleway (Infrastructure & Kubernetes):
|
|
|
|
|
|
|
|
|
|
- ISO/IEC 27001:2022 certified for Information Security Management Systems Our certifications & security | Scaleway
|
|
|
|
|
- HDS (Hébergeur de Données de Santé) certified for health data hosting since July 2024 Our certifications & security | Scaleway
|
|
|
|
|
- Pursuing SecNumCloud qualification, the French certification for highest standards of security and compliance for sensitive data Our certifications & security | Scaleway
|
|
|
|
|
- GDPR compliant
|
|
|
|
|
- French cloud provider subject to European data protection regulations
|
|
|
|
|
|
|
|
|
|
Bunny.net (CDN & Security Layer):
|
|
|
|
|
|
|
|
|
|
- ISO 27001 certified (achieved January 2025) Raising the bar on security, bunny.net achieves ISO 27001 certification
|
|
|
|
|
- SOC 2 Type II certified
|
|
|
|
|
- GDPR compliant
|
|
|
|
|
- European company with full EU data routing capabilities
|
|
|
|
|
- PCI compliant
|
|
|
|
|
|
|
|
|
|
Mistral AI (AI Services):
|
|
|
|
|
|
|
|
|
|
- SOC 2 Type II certified Do you have SOC2 or ISO27001 Certification? | Mistral AI - Help Center
|
|
|
|
|
- ISO 27001/27701 certified Do you have SOC2 or ISO27001 Certification? | Mistral AI - Help Center
|
|
|
|
|
- GDPR compliant
|
|
|
|
|
- French AI provider
|
|
|
|
|
|
|
|
|
|
Strategic Provider Selection:
|
|
|
|
|
We deliberately selected European cloud service providers for several critical reasons:
|
|
|
|
|
|
|
|
|
|
- Full compliance with GDPR and European data protection regulations
|
|
|
|
|
- Data sovereignty - all customer data remains within European jurisdiction
|
|
|
|
|
- Subject to strict European privacy laws and oversight
|
|
|
|
|
- Alignment with our commitment to data protection and privacy
|
|
|
|
|
|
|
|
|
|
All our cloud providers maintain current, independently audited security certifications and undergo regular compliance assessments. This ensures that our infrastructure meets internationally recognised standards for information security, data protection, and operational reliability.
|
|
|
|
|
|
|
|
|
|
## Are communications between your organization and cloud provider environments restricted to only authenticated and authorized connections?
|
|
|
|
|
|
|
|
|
|
Yes, all communications between our organisation and cloud provider environments are strictly restricted to authenticated and authorised connections only.
|
|
|
|
|
Access Control & Authentication:
|
|
|
|
|
Scaleway (Infrastructure):
|
|
|
|
|
|
|
|
|
|
- All access controlled through Scaleway IAM (Identity and Access Management)
|
|
|
|
|
- API access exclusively via IAM-authenticated credentials
|
|
|
|
|
- Access restricted to authorised personnel only
|
|
|
|
|
- All services deployed within private network infrastructure
|
|
|
|
|
- No direct SSH access to production systems
|
|
|
|
|
|
|
|
|
|
Bunny.net (CDN & Security):
|
|
|
|
|
|
|
|
|
|
- Multi-factor authentication (MFA) enabled and enforced
|
|
|
|
|
- Secure password management via Proton Pass
|
|
|
|
|
- Dashboard access restricted to authorised personnel only
|
|
|
|
|
- Administrative access tightly controlled
|
|
|
|
|
|
|
|
|
|
Mistral AI (AI Services):
|
|
|
|
|
|
|
|
|
|
- API key-based authentication for service integration
|
|
|
|
|
- Credentials securely stored in Scaleway Secret Manager
|
|
|
|
|
- API keys imported into Kubernetes secrets for runtime use
|
|
|
|
|
- Console access with standard authentication mechanisms
|
|
|
|
|
|
|
|
|
|
Secure Communications:
|
|
|
|
|
Encryption in Transit:
|
|
|
|
|
|
|
|
|
|
- All connections encrypted using HTTPS/TLS protocols
|
|
|
|
|
- TLS encryption for internal service communications (PostgreSQL, Redis)
|
|
|
|
|
- Certificate-based authentication for database connections
|
|
|
|
|
|
|
|
|
|
Network Security:
|
|
|
|
|
|
|
|
|
|
- All Scaleway services deployed in private network (VPC)
|
|
|
|
|
- Database and cache services accessible only within secure network perimeter
|
|
|
|
|
- Connection pooling for secure service-to-container communication
|
|
|
|
|
|
|
|
|
|
Credential Management:
|
|
|
|
|
|
|
|
|
|
- All service credentials stored in Scaleway Secret Manager
|
|
|
|
|
- Secrets automatically imported into Kubernetes secrets for runtime access
|
|
|
|
|
- Username/password authentication for Redis and PostgreSQL with connection pooling
|
|
|
|
|
- API keys for external service integration (Mistral AI) securely managed
|
|
|
|
|
- No credentials stored in code or configuration files
|
|
|
|
|
|
|
|
|
|
Multi-Factor Authentication:
|
|
|
|
|
|
|
|
|
|
- MFA enabled on all platforms that support it (Bunny.net, Scaleway, etc.)
|
|
|
|
|
- Additional authentication layer for administrative access
|
|
|
|
|
|
|
|
|
|
All authentication mechanisms follow the principle of least privilege, ensuring that access is granted only to authorised users and services, with credentials securely managed and communications encrypted end-to-end.
|
|
|
|
|
|
|
|
|
|
## Are cloud assets (related to the provided system/service) protected at the network and application layers from malicious attacks?
|
|
|
|
|
|
|
|
|
|
Yes, our cloud assets are protected at both the network and application layers through multiple security controls designed to defend against malicious attacks.
|
|
|
|
|
Network Layer Protection:
|
|
|
|
|
Perimeter Security:
|
|
|
|
|
|
|
|
|
|
- Bunny.net Shield providing comprehensive protection including:
|
|
|
|
|
- Web Application Firewall (WAF) with cutting-edge threat detection
|
|
|
|
|
- Advanced rate limiting to prevent abuse
|
|
|
|
|
- Robust DDoS mitigation capabilities
|
|
|
|
|
- All external traffic routed exclusively through Bunny.net security layer
|
|
|
|
|
- No direct exposure of backend infrastructure to the internet
|
|
|
|
|
|
|
|
|
|
Network Segmentation:
|
|
|
|
|
|
|
|
|
|
- Kubernetes cluster deployed in private network (Scaleway VPC)
|
|
|
|
|
- Internal services (PostgreSQL, Redis) isolated within private network
|
|
|
|
|
- Scaleway firewall protections applied at infrastructure level
|
|
|
|
|
- Administrative access restricted via secure port-forwarding only
|
|
|
|
|
|
|
|
|
|
Encryption:
|
|
|
|
|
|
|
|
|
|
- TLS encryption for all external communications (browser → Bunny.net → Kubernetes)
|
|
|
|
|
- TLS encryption for internal service communications (PostgreSQL, Redis)
|
|
|
|
|
- End-to-end encrypted data transmission
|
|
|
|
|
|
|
|
|
|
Application Layer Protection:
|
|
|
|
|
Authentication & Authorisation:
|
|
|
|
|
|
|
|
|
|
- API authentication using API keys and JWT tokens
|
|
|
|
|
- Multi-tenant architecture with strict data isolation per tenant
|
|
|
|
|
- Role-based access control within the application
|
|
|
|
|
- Password hashing (no plain text storage)
|
|
|
|
|
|
|
|
|
|
Common Vulnerability Protection:
|
|
|
|
|
|
|
|
|
|
- Security headers implemented across the application
|
|
|
|
|
- SQL injection prevention through parameterised queries and ORM usage
|
|
|
|
|
- Cross-Site Scripting (XSS) protection via DOM inspection and input sanitisation
|
|
|
|
|
- Input validation and sanitisation for all user-supplied data
|
|
|
|
|
- Standard Flask security frameworks deployed
|
|
|
|
|
- OWASP Top 10 awareness with ongoing verification
|
|
|
|
|
|
|
|
|
|
Data Protection:
|
|
|
|
|
|
|
|
|
|
- Multi-tenant data isolation (separate database schemas and object storage per tenant)
|
|
|
|
|
- Secure session management
|
|
|
|
|
- Protection against common web vulnerabilities
|
|
|
|
|
|
|
|
|
|
Defence-in-Depth Strategy:
|
|
|
|
|
Our security approach implements multiple layers of protection:
|
|
|
|
|
|
|
|
|
|
- Edge protection via Bunny.net Shield (WAF, DDoS, rate limiting)
|
|
|
|
|
- Network isolation and segmentation
|
|
|
|
|
- Application-level security controls
|
|
|
|
|
- Data-level protections (encryption, isolation)
|
|
|
|
|
|
|
|
|
|
Planned Enhancements:
|
|
|
|
|
|
|
|
|
|
- Application-level rate limiting
|
|
|
|
|
- Enhanced security monitoring and alerting for attack detection
|
|
|
|
|
- Comprehensive OWASP Top 10 verification and remediation
|
|
|
|
|
- Automated security testing in CI/CD pipeline
|
|
|
|
|
|
|
|
|
|
Our layered security approach ensures that even if one layer is compromised, additional protections remain in place to safeguard our systems and customer data.
|
|
|
|
|
|
|
|
|
|
## Are the security-relevant events (related to provided system/service) in cloud environments identified and logged?
|
|
|
|
|
|
|
|
|
|
Yes, security-relevant events are identified and logged throughout our cloud environments, providing visibility into security incidents and operational issues.
|
|
|
|
|
Centralised Logging Infrastructure:
|
|
|
|
|
Scaleway Cockpit (Prometheus & Grafana):
|
|
|
|
|
|
|
|
|
|
- Centralised log aggregation for all infrastructure and application components
|
|
|
|
|
- Default retention: 7 days for logs, 31 days for metrics
|
|
|
|
|
- Structured log collection using Promtail from all application containers
|
|
|
|
|
- Kubernetes cluster logs (control plane, nodes, system applications)
|
|
|
|
|
- Infrastructure logs (PostgreSQL, Redis, Object Storage)
|
|
|
|
|
- Application logs from all containerised services
|
|
|
|
|
|
|
|
|
|
Application-Level Logging:
|
|
|
|
|
Security Events:
|
|
|
|
|
|
|
|
|
|
- Authentication attempts (successful and failed) logged
|
|
|
|
|
- User actions and data modifications tracked (current state stored in database)
|
|
|
|
|
- Errors and exceptions comprehensively logged
|
|
|
|
|
- AI specialist interactions fully logged (with limited retention for data protection)
|
|
|
|
|
|
|
|
|
|
Operational Logging:
|
|
|
|
|
|
|
|
|
|
- API request and response logging (selective, not full scope)
|
|
|
|
|
- Backend application logging for investigation and root cause analysis
|
|
|
|
|
- Container and pod logs automatically collected
|
|
|
|
|
|
|
|
|
|
Infrastructure Security Logging:
|
|
|
|
|
Network & Infrastructure:
|
|
|
|
|
|
|
|
|
|
- Kubernetes cluster events and system logs
|
|
|
|
|
- Managed service logs (PostgreSQL, Redis) captured via Scaleway Cockpit
|
|
|
|
|
- Infrastructure changes and configuration modifications
|
|
|
|
|
|
|
|
|
|
External Security Layer (Bunny.net):
|
|
|
|
|
|
|
|
|
|
- WAF logs accessible via API showing blocked and allowed traffic, triggered rules, and security events Bunny StreamBunny Stream
|
|
|
|
|
- Real-time monitoring of processed requests, triggered rules, logged events, and blocked requests Metrics & Logging
|
|
|
|
|
- DDoS mitigation events
|
|
|
|
|
- Rate limiting violations
|
|
|
|
|
- Access logs and traffic patterns
|
|
|
|
|
|
|
|
|
|
Monitoring Capabilities:
|
|
|
|
|
|
|
|
|
|
- Business event monitoring (Prometheus, Grafana)
|
|
|
|
|
- Systems monitoring for all Scaleway resources (Scaleway Cockpit)
|
|
|
|
|
- Real-time log viewing and analysis through Grafana dashboards
|
|
|
|
|
- Ability to correlate events within Scaleway infrastructure
|
|
|
|
|
|
|
|
|
|
Planned Enhancements:
|
|
|
|
|
|
|
|
|
|
- Automated alerting for security events (infrastructure ready, configuration pending)
|
|
|
|
|
- Extended log retention periods for compliance requirements
|
|
|
|
|
- Cross-provider log correlation capabilities
|
|
|
|
|
- Enhanced security event monitoring and automated response
|
|
|
|
|
- Formal security event review procedures
|
|
|
|
|
|
|
|
|
|
Whilst we have comprehensive logging in place, we recognise that as we scale, we will need to implement automated alerting, extended retention policies, and more sophisticated security event analysis to proactively detect and respond to threats.
|
|
|
|
|
|
|
|
|
|
## Is there a defined encryption protocol in place for data in transit to/from the cloud environment.
|
|
|
|
|
|
|
|
|
|
Yes, we have defined encryption protocols in place for all data in transit to and from our cloud environments.
|
|
|
|
|
External Communications Encryption:
|
|
|
|
|
Client to Application:
|
|
|
|
|
|
|
|
|
|
- All browser traffic encrypted using HTTPS/TLS
|
|
|
|
|
- TLS termination at Bunny.net CDN layer
|
|
|
|
|
- Modern TLS protocols enforced (TLS 1.2 minimum, with TLS 1.3 support)
|
|
|
|
|
- Let's Encrypt certificates for domain authentication
|
|
|
|
|
- Automatic certificate renewal through Let's Encrypt integration
|
|
|
|
|
- Traffic flow: Browser (HTTPS/TLS) → Bunny.net (HTTPS/TLS) → Scaleway Kubernetes
|
|
|
|
|
|
|
|
|
|
Email Communications:
|
|
|
|
|
|
|
|
|
|
- Proton Mail Business with TLS 1.2+ encryption for all email transit
|
|
|
|
|
- End-to-end encryption for Proton-to-Proton communications
|
|
|
|
|
- TLS encryption for external email providers
|
|
|
|
|
- Zero-access encryption for emails at rest
|
|
|
|
|
|
|
|
|
|
Internal Service Communications:
|
|
|
|
|
Database and Cache Connections:
|
|
|
|
|
|
|
|
|
|
- PostgreSQL: TLS encryption with certificate-based authentication
|
|
|
|
|
- Redis: TLS encryption for all connections
|
|
|
|
|
- Secure connection pooling for application-to-database communications
|
|
|
|
|
|
|
|
|
|
API Communications:
|
|
|
|
|
|
|
|
|
|
- Mistral AI: HTTPS/TLS encrypted API calls
|
|
|
|
|
- All external service integrations use HTTPS/TLS protocols
|
|
|
|
|
- API keys securely transmitted over encrypted channels
|
|
|
|
|
|
|
|
|
|
Object Storage:
|
|
|
|
|
|
|
|
|
|
- Scaleway Object Storage: HTTPS for all uploads and downloads through platform
|
|
|
|
|
- Bunny.net Storage: TLS encryption for static file uploads (via Forklift)
|
|
|
|
|
|
|
|
|
|
Administrative Access:
|
|
|
|
|
Cluster Management:
|
|
|
|
|
|
|
|
|
|
- kubectl port-forward: Encrypted TLS tunnel between local machine and Kubernetes API server
|
|
|
|
|
- Secure, encrypted connection for accessing internal tools (PgAdmin, RedisInsight, etc.)
|
|
|
|
|
- No direct SSH access to production systems
|
|
|
|
|
|
|
|
|
|
Infrastructure Management:
|
|
|
|
|
|
|
|
|
|
- Scaleway IAM API access over HTTPS/TLS
|
|
|
|
|
- Bunny.net dashboard access over HTTPS with MFA
|
|
|
|
|
- All administrative interfaces accessed via encrypted connections
|
|
|
|
|
|
|
|
|
|
Certificate Management:
|
|
|
|
|
|
|
|
|
|
- Let's Encrypt as certificate authority for all domains
|
|
|
|
|
- Certificates stored securely in Kubernetes secrets
|
|
|
|
|
- Automatic certificate validation and trust chain verification
|
|
|
|
|
|
|
|
|
|
Protocol Standards:
|
|
|
|
|
|
|
|
|
|
- Minimum TLS version: TLS 1.2 (industry best practice)
|
|
|
|
|
- Support for TLS 1.3 where available
|
|
|
|
|
- Deprecated and insecure protocols (SSL 3.0, TLS 1.0, TLS 1.1) not supported
|
|
|
|
|
- Strong cipher suites enforced
|
|
|
|
|
|
|
|
|
|
Areas for Enhancement:
|
|
|
|
|
|
|
|
|
|
- Inter-pod communication within Kubernetes cluster currently relies on network isolation rather than encryption (service mesh/mTLS not yet implemented)
|
|
|
|
|
- Formal TLS version enforcement policy to be documented
|
|
|
|
|
- Certificate rotation policy to be formalised
|
|
|
|
|
- Consideration of service mesh (e.g., Istio, Linkerd) for mutual TLS between microservices as we scale
|
|
|
|
|
|
|
|
|
|
All data in transit between our systems, cloud providers, and end-users is protected using industry-standard encryption protocols, ensuring confidentiality and integrity of communications.
|
Josako