Security Incident Response Policy

1. Scope and Objectives

1.1 Scope

This Policy applies to all security incidents affecting the Vora platform operated by Cathedral s.r.l.s, including but not limited to:

• The Vora backend API infrastructure (api.cathedral.technology)
• The Vora frontend web application (voiceofthenewera.com)
• The Vora Shopify application and its theme app extensions
• The Vora blockchain infrastructure, including smart contracts deployed on Polygon, Base, and Ethereum networks
• All databases, servers, and cloud infrastructure supporting the platform
• All Personal Data processed on behalf of merchants (Controllers) and their customers (Data Subjects)

1.2 Objectives

The objectives of this Policy are to:

• Minimise the impact and duration of security incidents on the platform and its users
• Ensure timely and compliant notification to supervisory authorities and affected individuals in accordance with GDPR Articles 33 and 34
• Preserve evidence and maintain comprehensive documentation for regulatory and legal purposes
• Restore normal operations as swiftly as possible while safeguarding data integrity
• Continuously improve security posture through post-incident analysis and corrective actions

2. Definitions

3. Incident Classification

Security incidents are classified into four severity levels to ensure proportionate response and resource allocation:

4. Incident Response Team

The Incident Response Team ("IRT") is responsible for managing all phases of the incident lifecycle. The IRT comprises the following roles:

5. Detection and Identification

Cathedral employs multiple detection mechanisms to identify potential security incidents across the Vora platform:

5.1 Automated Monitoring

• Structured Application Logging — All application events are recorded in structured JSON format via centralised logging, capturing component identifiers, request correlation IDs, user context, and error details. Logs are written to rotating files with separate error-level streams for rapid triage.
• Request Tracing — Every API request is assigned a unique request identifier (X-Request-ID) that propagates through all system components, enabling end-to-end tracing of suspicious activity.
• Database Audit Trails — Critical data models maintain historical change records, capturing the timestamp, user, and nature of every modification to sensitive data including votes, governance outcomes, and user account changes.
• Blockchain Transaction Monitoring — All on-chain transactions are tracked through the blockchain processing queue, with status monitoring for each vote certification and Merkle batch submission across all deployed chains.
• Infrastructure Monitoring — Server health, resource utilisation, and service status are continuously monitored. Database performance metrics including slow query logging (queries exceeding 500ms) and connection pool health are tracked.

5.2 Manual Detection Channels

• Merchant Reporting — Merchants may report security concerns via security@cathedral.technology.
• Customer Reporting — End users may report security issues via support@cathedral.technology.
• Internal Discovery — Staff members who identify potential security issues during routine operations must report them immediately to the Incident Commander.
• Shopify Notification — Security alerts received from Shopify regarding the Vora Shopify application are treated as potential incidents and triaged accordingly.

5.3 Initial Assessment

Upon detection, the following initial assessment steps are performed:

1. Verify the event is a genuine security incident (eliminate false positives)
2. Determine the scope: which systems, data, and users are affected
3. Classify the severity level in accordance with Section 3
4. Determine whether Personal Data has been or may have been compromised
5. Activate the Incident Response Team at the appropriate escalation level
6. Begin the incident documentation log with the timestamp of detection, nature of the event, and initial findings

6. Containment and Eradication

6.1 Immediate Containment

The priority is to limit the scope and impact of the incident. Depending on the nature and severity, immediate containment actions may include:

• Isolating affected servers or services from the network
• Suspending the Vora API service (ASGI application server) and blockchain processing daemon to prevent further data exposure
• Revoking compromised API keys, access tokens, or session credentials
• Blocking malicious IP addresses or traffic patterns at the reverse proxy level
• Rotating database credentials and encryption keys
• Suspending the Shopify application if the incident originates from or affects the Shopify integration

6.2 Evidence Preservation

Before eradication, the following evidence is preserved:

• Full application log archives (structured JSON logs) covering the incident period
• Database audit trail exports and historical model change records
• Blockchain transaction records (immutable by nature; on-chain data cannot be altered)
• Server access logs, system logs, and network flow data
• Database query logs including slow query records
• Memory dumps or filesystem snapshots where relevant

6.3 Eradication

Once the incident is contained and evidence preserved, the root cause is identified and eliminated:

• Patching or remediating the exploited vulnerability
• Removing any malicious code, unauthorised accounts, or backdoors
• Verifying the integrity of application code, database schema, and blockchain smart contract state
• Conducting a comprehensive review of access controls and authentication mechanisms
• Validating that all OAuth tokens, API keys, and session data have been rotated where affected

7. Notification Obligations

7.1 Notification to Supervisory Authority

Where the incident constitutes a Personal Data Breach that is likely to result in a risk to the rights and freedoms of natural persons, Cathedral shall notify the Italian Data Protection Authority (Garante per la protezione dei dati personali) within 72 hours. The notification shall include:

• The nature of the Personal Data Breach, including where possible, the categories and approximate number of Data Subjects concerned and the categories and approximate number of Personal Data records concerned
• The name and contact details of our Data Protection Officer
• A description of the likely consequences of the breach
• A description of the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects

7.2 Notification to Affected Merchants (Controllers)

As a Processor under our Data Processing Agreement, Cathedral shall notify affected merchants without undue delay after becoming aware of a Personal Data Breach affecting their data. This notification shall include:

• The nature and scope of the breach
• The categories of data affected (e.g., customer email addresses, voting records, purchase data)
• The measures taken to contain and remediate the breach
• Recommended actions for the merchant to take to protect their customers
• Contact details for ongoing communication regarding the incident

7.3 Notification to Data Subjects

Where the breach is likely to result in a high risk to the rights and freedoms of natural persons (GDPR Article 34), Cathedral shall, in coordination with the affected merchants (Controllers), communicate the breach to the affected Data Subjects without undue delay. This communication shall:

• Describe, in clear and plain language, the nature of the Personal Data Breach
• Provide the name and contact details of our Data Protection Officer
• Describe the likely consequences of the breach
• Describe the measures taken or proposed to address the breach and mitigate its effects
• Provide specific guidance on steps Data Subjects can take to protect themselves

7.4 Notification to Shopify

Where the incident affects the Vora Shopify application or data processed through the Shopify integration, Cathedral shall notify Shopify in accordance with the Shopify Partner Programme requirements and applicable API terms of service.

7.5 Exceptions to Data Subject Notification

Notification to Data Subjects is not required where any of the following conditions are met (GDPR Article 34(3)):

• The Personal Data affected was rendered unintelligible through encryption or other technical measures, and the key has not been compromised
• Subsequent measures have been taken that ensure the high risk to the rights and freedoms of Data Subjects is no longer likely to materialise
• Notification would involve disproportionate effort, in which case a public communication or similar measure shall be used instead

8. Recovery and Restoration

8.1 System Restoration

Recovery follows a structured approach to restore services safely:

1. Integrity Verification — Verify the integrity of all application code, database contents, and configuration files before restoring services
2. Database Recovery — Restore the PostgreSQL database from verified backups if data integrity has been compromised. Validate data consistency using historical change records and audit trails
3. Blockchain Verification — Verify on-chain records against off-chain database state. Blockchain records are immutable and serve as an independent verification source for governance outcomes and vote certifications
4. Service Restoration — Restart platform services in a controlled sequence: database first, then the application server, then the blockchain processing daemon
5. Monitoring — Implement enhanced monitoring during the recovery period to detect any recurrence of the incident

8.2 Business Continuity

During the incident, Cathedral shall:

• Maintain communication with affected merchants regarding service status and expected restoration timeline
• Prioritise the restoration of core platform functionality (authentication, governance, voting) followed by ancillary services (analytics, reporting)
• Where possible, maintain read-only access to governance data and blockchain-verified records while write operations are suspended

9. Post-Incident Review

Within fourteen (14) calendar days of incident resolution, the Incident Response Team shall conduct a comprehensive post-incident review ("post-mortem") that documents:

9.1 Review Contents

• Timeline — A detailed chronological account of the incident from initial detection through to full resolution
• Root Cause Analysis — Identification of the underlying cause(s) of the incident, distinguishing between technical, procedural, and human factors
• Impact Assessment — Quantification of the incident's impact, including the number of affected users, data records involved, duration of service disruption, and any financial implications
• Response Evaluation — Assessment of the effectiveness of the incident response, including time-to-detection, time-to-containment, and time-to-resolution metrics
• Corrective Actions — Specific, actionable recommendations to prevent recurrence, with assigned owners and target completion dates
• Policy Updates — Identification of any changes required to this Policy, the Privacy Policy, or other security procedures

9.2 Lessons Learned

Findings from the post-incident review are incorporated into:

• The platform's security controls and monitoring configuration
• Staff training and awareness materials
• Application code, infrastructure configuration, and deployment procedures
• Vendor and sub-processor risk assessments

10. Preventive Security Controls

Cathedral maintains the following preventive controls to reduce the likelihood and impact of security incidents:

10.1 Access Controls

• SSH key-based authentication for all server access (password authentication is disabled)
• Role-based access control within the Django administration panel, restricted to authorised personnel
• OAuth 2.0 authentication for the Shopify application integration
• JWT-based session management with configurable token expiration for platform users
• Optional two-factor authentication (TOTP) for Vora accounts holding administrative roles

10.2 Encryption

• In Transit — All data transmitted between clients and the platform is encrypted using TLS (HTTPS enforced across all endpoints)
• At Rest — Database storage utilises encrypted EBS volumes. Passwords are stored using Django's PBKDF2 hashing with SHA-256
• Blockchain — Cryptographic signatures (ECDSA) secure all blockchain transactions. Private keys are stored in encrypted environment variables, never in source code

10.3 Database Security

• PostgreSQL configured with statement timeouts (30 seconds) and idle-in-transaction timeouts (60 seconds) to prevent resource exhaustion attacks
• Connection limits enforced to prevent denial-of-service through connection pool exhaustion
• Slow query logging enabled for queries exceeding 500ms, facilitating detection of injection attempts or abnormal query patterns
• Automated data retention policies (90-day cleanup for analytics data) to minimise the volume of stored Personal Data

10.4 Application Security

• Django's built-in CSRF, XSS, and SQL injection protections are enabled across all endpoints
• GDPR compliance webhooks (customers/data_request, customers/redact, shop/redact) are implemented for the Shopify integration
• Input validation and sanitisation on all user-facing API endpoints
• Dependency vulnerability scanning as part of the deployment process

11. Blockchain Data Integrity Assurance

The Vora platform utilises blockchain technology to provide an additional, independent layer of data integrity assurance for governance outcomes:

11.1 Immutable Audit Trail

• Governance votes and outcomes are certified on-chain via smart contracts deployed on public blockchain networks
• Each vote certification includes a cryptographic hash of the governance data, creating a tamper-proof record
• Merkle tree batching aggregates multiple votes into single on-chain submissions, with each individual vote independently verifiable via its Merkle proof

11.2 Incident Relevance

In the event of a security incident affecting the off-chain database:

• On-chain records serve as an independent, immutable source of truth for governance data integrity verification
• The public, verifiable nature of blockchain records provides transparent evidence that governance outcomes have not been altered
• Cross-referencing off-chain data against on-chain records is part of the standard recovery integrity verification procedure

12. Third-Party and Sub-Processor Incidents

Where a security incident originates from or involves a third-party service or sub-processor used by the Vora platform, the following additional procedures apply:

12.1 Sub-Processors

Cathedral's current sub-processors include cloud infrastructure providers and blockchain network providers. In accordance with our Data Processing Agreement, all sub-processors are contractually obligated to:

• Notify Cathedral without undue delay upon becoming aware of a security incident affecting Vora data
• Cooperate fully in the investigation and remediation of the incident
• Maintain security standards consistent with the requirements of this Policy

12.2 Shopify Platform

As the Vora Shopify application operates within the Shopify ecosystem, incidents may involve interactions between the Vora application and the Shopify platform. In such cases:

• Cathedral shall coordinate with Shopify's security team in accordance with Shopify Partner Programme requirements
• Access scope is minimised to read-only permissions (read_customers, read_products, read_orders) to limit the impact of any credential compromise
• All communication between the Vora application and Shopify APIs is conducted over authenticated, encrypted channels

13. Training and Awareness

• All personnel with access to the Vora platform infrastructure are trained on this Policy and their responsibilities in the event of a security incident
• Training is provided upon onboarding and refreshed annually, or whenever material changes are made to this Policy
• Incident response procedures are tested periodically to validate their effectiveness and identify areas for improvement
• All personnel are trained to recognise common attack vectors, including phishing, social engineering, and credential compromise

14. Record Retention

Cathedral maintains comprehensive records of all security incidents in accordance with GDPR Article 33(5):

• Incident Documentation — All incident reports, including detection records, response actions, notifications sent, and post-incident reviews, are retained for a minimum of five (5) years from the date of incident resolution
• Application Logs — Structured application logs are retained for fourteen (14) days in active storage, with compressed archives retained for sixty (60) days
• Database Audit Trails — Historical change records for critical data models are retained for the duration of the service agreement plus twelve (12) months
• Blockchain Records — On-chain records are permanently and immutably stored on the respective blockchain networks and cannot be deleted or modified

15. Policy Review and Updates

• This Policy is reviewed at least annually and updated as necessary to reflect changes in the platform's architecture, threat landscape, regulatory requirements, or organisational structure
• Material changes to this Policy are communicated to affected merchants and published on this page with an updated version number and date
• This Policy is additionally reviewed following every Critical (P1) or High (P2) severity incident

16. Contact Information

To report a security incident or vulnerability, or for any questions regarding this Policy, please contact: