Security Policy

1.1 Purpose

This security policy establishes guidelines and procedures for safeguarding our website infrastructure, protecting customer data, and maintaining the integrity of our point-of-sale software solutions for quick-service restaurants.

1.2 Scope

This policy applies to all employees, contractors, vendors, and third parties who have access to, manage, or maintain our website infrastructure, applications, and data.

1.3 Compliance Statement

Radish acknowledges that it is not currently PCI DSS compliant. We have established this security policy as part of our efforts to protect sensitive data.

2.1 Data Classification

All data handled by our systems is classified into the following categories:

• Highly Sensitive - Payment card information, authentication credentials‍
• Sensitive - Customer personal information, order history, business analytics‍
• Internal - Non-public company information, internal communications‍
• Public - Information available on our public website

2.2 Data Handling Requirements

• Highly Sensitive Data: Payment card information must not be stored, processed, or transmitted through our systems. All payment processing must be outsourced to PCI-compliant third-party processors with no card data touching our infrastructure.
• Sensitive Data: Must be encrypted at rest and in transit. Access restricted to authorized personnel only.
• Internal Data: Access limited to employees with a business need.
• Public Data: Approved for public disclosure.

4.1 Network Security

All data handled by our systems is classified into the following categories:

• Web Application Firewall (WAF) implementation
• Regular vulnerability scanning (minimum monthly)
• DDoS protection services
• Network segmentation to isolate production environments

4.2 Application Security

• Input validation on all form fields
• Output encoding to prevent XSS attacks
• Regular security code reviews
• External penetration testing conducted annually

4.3 SSL/TLS and Encryption Requirements

4.3.1 SSL/TLS Configuration

• HTTPS must be implemented across the entire website with no mixed content
• TLS 1.2 or higher must be used; TLS 1.0 and 1.1 must be disabled
• SSL certificates must be obtained from trusted Certificate Authorities (CAs)
• Certificates must be renewed at least 30 days before expiration
• Auto-renewal processes should be implemented where possible
• HTTP Strict Transport Security (HSTS) headers must be enabled
• HTTP to HTTPS redirects must be configured for all web pages
• Minimum key length of 2048 bits for RSA keys
• Forward Secrecy must be enabled in the TLS configuration
• Strong cipher suites must be used and weak ciphers disabled

4.3.2 SSL/TLS Monitoring

• Weekly automated checks for certificate expiration
• Monthly validation of SSL/TLS configuration using tools like SSL Labs Server Test
• Immediate remediation of any SSL/TLS vulnerabilities identified

4.3.3 Other Encryption Requirements

• Secure key management procedures
• Encryption of data backups containing sensitive information

5.1 Security Incident Definitions

A security incident includes, but is not limited to:

• Unauthorized access to systems or data
• Data breaches or potential data exposure
• Website defacement
• Malware infections
• DDoS attacks
• Phishing attempts targeting our organization

5.2 Incident Response Procedure

• Detection and Reporting: All employees must report suspected security incidents immediately to the Security Team.
• Assessment and Containment: The Security Team will assess the incident severity and implement containment measures.
• Investigation: Root cause analysis conducted to determine the source and impact of the incident.
• Remediation: Implementation of measures to address the vulnerability and prevent similar incidents.
• Recovery: Return systems to normal operations.
• Notification: Determine if notification to customers or regulatory bodies is required.
• Post-Incident Review: Document lessons learned and update security controls as needed.

6.1 Training Requirements

• All employees must complete security awareness training upon hiring and annually thereafter.
• Developers must receive specialized secure coding training.
• System administrators must be trained on secure system configuration.

6.2 Security Policies Acknowledgment

All employees must read and acknowledge this security policy as part of their onboarding process and after any major updates to the policy.

7.1 Regular Assessments

• Quarterly internal security assessments
• Annual external penetration testing
• Continuous automated vulnerability scanning

7.2 Documentation Requirements

All security assessments must be documented, including:

• Identified vulnerabilities
• Risk ratings
• Remediation plans with deadlines
• Verification of remediation effectiveness

8.1 Backup Procedures

• Daily incremental backups of all systems
• Weekly full backups
• Monthly backup restoration testing
• Offsite storage of backup media

8.2 Disaster Recovery

• Documented disaster recovery procedures
• Annual testing of recovery capabilities
• Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) defined for all critical systems

9.1 Annual Review

This policy will be reviewed at least annually and updated as needed.

9.2 Change Management

All changes to this policy must be approved by executive management and communicated to all affected parties.