Information Security Policy

Purpose and scope

FunPeople adopts this policy to protect the confidentiality, integrity and availability of information used to operate FunPeople.com. It applies to personnel, contractors, systems and service providers handling FunPeople information, including the website, source code, hosting, business email, contact submissions and authorized commerce integrations.

This policy establishes required practices. Publication does not certify that every control has been independently verified or audited. Control implementation must be documented separately.

Ownership and review

The policy owner is responsible for approving access, assigning security responsibilities, reviewing material risks and exceptions, and coordinating incident response. Personnel must understand and follow this policy before receiving access to FunPeople systems.

The owner must review this policy at least annually and after material changes to the service, its information, providers or risks. Policy changes must be versioned. Control gaps must be recorded with an accountable owner, corrective action and review date. Exceptions require documented approval and an expiry date and cannot override applicable legal or platform requirements.

Information classification and collection

Published directory content is public. Nonpublic operational records are internal. Contact submissions, nonpublic personal information, credentials, API tokens and incident records are restricted. When classification is uncertain, information must receive the more protective treatment until the owner resolves it.

Only information needed for a defined service or business purpose may be collected. Before a new integration begins processing data, its operator must document the data sources, intended use, recipients, storage and processing locations, retention periods and access requirements.

Commerce data may be accessed only through authorized methods and approved permissions. The directory must not collect marketplace passwords or payment card details. Any expansion to additional sensitive information requires a documented security review before collection.

Access control

Access must have an approved business need and use the minimum necessary permissions. Administrative access must use individually assigned accounts and multifactor authentication where supported. Passwords must be unique and stored in an approved password manager. Shared administrative credentials must be avoided.

Access must be reviewed at least annually and when responsibilities change. Access must be removed promptly when no longer required. Production permissions must be separated from routine browsing, editorial work and development wherever the systems support that separation.

Credentials, encryption and devices

Secrets must be stored in access controlled secret storage or protected server configuration, separate from source code. Credentials and restricted commerce information must not appear in public pages, browser code, repositories or general application logs. Suspected credential exposure requires prompt revocation or rotation and investigation.

Restricted information must use encrypted connections in transit and appropriate encrypted storage at rest, including backups. Operators must verify the relevant provider configuration before storing restricted information.

Access devices must use supported software, security updates, screen locks, device encryption where supported, and appropriate malware protection. Restricted information must not be placed on unmanaged devices or unapproved services. Network access and administrative interfaces must be limited to authorized use.

Changes, vulnerabilities and monitoring

Code, configuration and dependency changes must be recorded and reviewed in proportion to their security impact before production release. Releases must have a practical recovery or rollback method. Production credentials must not be used in public examples or test fixtures.

Operators must review relevant security advisories and dependency findings. Vulnerabilities must be prioritized by exploitability, exposure and potential impact. Known exploitation or a material risk to restricted information requires immediate containment or mitigation while a permanent correction is prepared.

Security and operational logs must support investigation without storing secrets or unnecessary personal information. Log access must be restricted and retention must have a documented purpose. Suspicious access or material security alerts must be assessed and escalated to the policy owner.

Service providers and recovery

Providers must be assessed before receiving restricted information or privileged access. The assessment must consider their role, permissions, security protections, processing locations, retention and deletion arrangements, and relevant contractual obligations. Material provider changes require reassessment.

Information needed to restore the service must have an appropriate backup, version history or reconstruction method. Restricted backups require equivalent protection. Recovery procedures must be documented and checked after material infrastructure changes and periodically according to risk.

Incident response and notification

Suspected unauthorized access, credential exposure, information loss or other security incidents must be reported promptly to the policy owner through the security contact. The owner acts as incident coordinator and assigns the responsible technical operator to investigate and contain the incident.

The response must include assessment, containment, preservation of relevant evidence, correction of the cause, recovery and a record of findings. The technical operator must restrict affected access, revoke exposed credentials where warranted, and verify safe recovery. The owner is responsible for communication decisions and follow-up.

Affected providers, commerce platforms, sellers, individuals and authorities must be notified when required by applicable obligations and within the relevant deadlines. Notices must distinguish confirmed facts from matters still under investigation. The owner must review the cause, response and corrective actions after a material incident.

Retention, deletion and individual requests

Restricted information must have a documented retention purpose and period. It must be deleted or anonymized when that purpose ends, subject to applicable obligations and documented preservation needs. Permissions and credentials must be revoked when an integration is discontinued or authorization is withdrawn.

Deletion procedures must account for operational systems, providers and backups. Platform information must follow the platform's access, retention and deletion requirements. Retained backups must be protected, expire under the retention schedule, and not reintroduce deleted information into active use.

Requests to access, correct or delete personal information must be routed to the policy owner, verified in proportion to their sensitivity, and handled under applicable obligations. FunPeople must assist the relevant platform or seller with valid requests concerning information in its control.

Report a security concern

Report suspected vulnerabilities or security incidents privately to privacy@funpeople.com. Include the affected URL, a description and enough information to reproduce the concern safely. Do not include passwords, access tokens or unnecessary personal information. Reports must be reviewed and routed to the policy owner.

The privacy notice explains how website contact information and technical information are handled. This security policy defines the operational requirements for protecting that information.