Search results

Purpose Define how Perfect Wiki detects, responds to, contains, recovers from, and learns from security and availability incidents. Scope Any actual or suspected event that could compromise the confidentiality, integrity, or availability of Perfect Wiki systems or customer data — including data breaches, account compromise, denial of service, vendor incidents, and material service degradations. Severity levels SEV1 — Critical: Confirmed data breach, full outage, or active attack. Immediate response, all hands. SEV2 — High: Partial outage, suspected breach, exploitable vulnerability discovered. Response within 1 hour. SEV3 — Medium: Degraded performance, low-severity vulnerability, vendor advisory affecting us. Response within 1 business day. SEV4 — Low: Single-user issue, informational alert. Response within 5 business days. Process Detection. Alerts arrive from Sentry, cron-job check-ins, the status-page monitor, customer reports to [email protected] mailto:[email protected] or vendor advisories. Triage.

Purpose Define how changes to Perfect Wiki production systems are proposed, reviewed, tested, deployed, and rolled back so changes do not compromise availability, security, or data integrity. Scope All changes to production application code, infrastructure configuration, cloud resources, third-party integrations, and customer-facing service behavior. Policy All production changes are made via version control (Git). Direct, unversioned modifications to production are prohibited. Each change passes type checking and manual functional testing on the staging environment before promotion to production. Production deployments are made from versioned, immutable container images. The previous image is retained to enable rapid rollback. Changes with security or data-integrity implications require explicit approval by the CEO/CTO. Database schema changes use forward-compatible patterns (additive Firestore fields, no destructive deletions) and are tested on staging first. Production cloud configuration (IAM, network, storage

Purpose Define how Perfect Wiki selects, onboards, monitors, and offboards third-party vendors — particularly sub-processors that handle customer data. Scope All third parties that store, process, or transmit Perfect Wiki customer data, or that materially affect the security or availability of the Perfect Wiki service. Selection criteria Vendor publishes a clear security posture and has an industry-recognized certification (SOC 2, ISO 27001) or a credible equivalent. Vendor's terms include a Data Processing Agreement compatible with GDPR. Vendor's data-handling locations and sub-processors are acceptable for Perfect Wiki's data-residency commitments. Vendor has a documented incident-notification process for customer-impacting events. Onboarding Document the data category that will be shared with the vendor and the business purpose. Execute the vendor's standard contract, including DPA, with terms requiring confidentiality and security controls at least equivalent to Perfect Wiki's own. Add the vendor to the public

Purpose Define security requirements for personnel — employees and contractors — before, during, and after engagement with Perfect Wiki. Scope All Perfect Wiki personnel and contractors who may access customer data, production systems, or confidential company information. Before engagement Identity verification of every candidate before access is provisioned. Background check (criminal record check, identity verification, and reference checks where lawful in the candidate's jurisdiction) for any personnel granted production access. Checks are proportional to the sensitivity of the role. Signed employment or contractor agreement that includes confidentiality, intellectual-property assignment, acceptable use, and obligation to comply with Perfect Wiki's information-security policies. Signed non-disclosure agreement covering customer data and trade secrets. During engagement Access provisioned per the Access Control & Identity Management Policy https://app.perfectwiki.xyz/?teamId=89c663c2-211c-4e7c-834c-b945c28cc308

Purpose Ensure that security is built into every stage of designing, building, and operating the Perfect Wiki application. Scope All code, infrastructure-as-code, and customer-facing changes to the Perfect Wiki service. Phases 1. Design New features that handle sensitive data or expand the attack surface are threat-modeled informally: identify data flows, trust boundaries, authentication / authorization requirements, and abuse cases. Privacy-by-design: minimize data collected, prefer references over copies, scope data to the tenant. 2. Build — secure coding standards TypeScript with strict types for all new backend code. Input validation via Zod schemas on every endpoint. Authentication and authorization enforced on every non-public endpoint via middleware (validateSessionId, validateUserHasAccessToOrganization, validateUserIsAdmin, role-specific variants). Output encoding / HTML sanitization for any user content rendered in HTML (sanitize-html). Parameterized queries via the Firestore SDK — no string-built queries.

Purpose Ensure that Perfect Wiki maintains awareness of its information assets and applies appropriate controls to them throughout their lifecycle. Scope All logical and physical assets that store, process, or transmit Perfect Wiki or customer data. Asset categories Production cloud resources: Google Cloud project (Firestore databases, Cloud Storage buckets, Pub/Sub topics, Redis instance, Cloud Run / Compute Engine workloads, IAM identities, service accounts). Application code & configuration: Source repositories, container images, build artifacts. SaaS & vendor consoles: Sentry, Cloudflare, Algolia, Qdrant, Azure OpenAI, Postmark, SendPulse, PostHog, FastSpring, Microsoft Partner Center, Slack App Directory, Google Cloud Console, Bitbucket. Endpoints: Personnel workstations used for development and operations. Data: Customer content, customer account data, operational logs, backups, billing records. Inventory An asset inventory is maintained covering the categories above, identifying for each asset: owner, business

This Data Processing Agreement (the "DPA") is entered into between the customer (the "Controller") and Perfect Wiki ("Processor") and forms part of the agreement governing the customer's use of the Perfect Wiki service (the "Agreement"). Where any conflict arises, this DPA prevails over the Agreement with respect to the processing of personal data. 1. Definitions Terms used in this DPA have the meanings given to them in the EU General Data Protection Regulation 2016/679 ("GDPR"). "Personal Data" means any information relating to an identified or identifiable natural person processed by Processor on behalf of Controller in connection with the Agreement. 2. Subject matter, duration, nature, and purpose Subject matter: Provision of the Perfect Wiki SaaS service. Duration: The term of the Agreement, plus the data-retention period defined in Perfect Wiki's Data Classification, Retention & Deletion Policy. Nature and purpose: Hosting, processing, search-indexing, AI-assisted querying, backing up, and supporting the

Perfect Wiki appreciates the work of the security community in keeping our customers safe. If you believe you've found a security vulnerability in our service, we want to hear from you. How to report Email: [email protected] mailto:[email protected] Use a clear subject line, e.g. "Security report: ". Include enough detail to reproduce: URL/endpoint, request payload, steps to reproduce, expected vs. actual behavior, impact, and screenshots or video where helpful. If possible, include suggested mitigation. If you discovered the issue with an automated tool, please reduce noise by validating the finding manually before submitting. What we commit to Acknowledge receipt of your report within 3 business days. Provide an initial assessment of the report within 10 business days. Keep you informed of remediation progress. Credit you in this page or in our changelog if you wish, once the issue is fixed. Not pursue legal action against researchers who follow the rules below in good faith. We're small company thus

Welcome to the Perfect Wiki Trust Center. This is the single source of truth for how we protect customer data, run our service securely, and meet our obligations to you. Security at a glance Encryption in transit: TLS 1.2+ with perfect forward secrecy on every endpoint. Encryption at rest: AES-256 (Google Cloud full-disk) for all customer data. Application-layer secrets are additionally encrypted with AES-256-GCM. Authentication: SSO via Microsoft Entra and Google Workspace, plus passwordless email OTP. MFA is inherited from the customer's identity provider. Hosting: Google Cloud Platform — US, Ireland, and Germany regions. Enterprise customers may pin data residency. Backups: Encrypted daily backups retained for up to 60 days, with documented restore procedure. Environment separation: Production, staging, and development environments are fully isolated. Production data is never used for non-production purposes. Monitoring: 24/7 automated monitoring and alerting via Sentry, with scheduled-job check-ins and uptime

Perfect Wiki uses the following third-party service providers ("sub-processors") to deliver the Perfect Wiki service. Each is bound by a contract requiring confidentiality and appropriate security measures, including a GDPR-compliant Data Processing Agreement where applicable. Infrastructure Sub-processor Purpose Data category Location Google Cloud Platform (Google LLC) Primary hosting — Firestore database, Cloud Storage, Pub/Sub, Compute All customer data US, Ireland, Germany (region selected closest to customer; Enterprise can pin) Cloudflare, Inc. CDN, DDoS protection, TLS termination at the edge Request metadata in transit Global AI & search Sub-processor Purpose Data category Location Azure OpenAI, L.L.C. LLM and embedding generation for AI search and Q&A Wiki content and queries sent to the AI assistant; API data is not used to train OpenAI models US Algolia, Inc. Full-text search indexing of wiki content Wiki titles and indexed content US / EU Qdrant Solutions GmbH Vector database for semantic search Vector

Purpose Define acceptable and prohibited uses of Perfect Wiki systems by personnel, and acceptable use of the Perfect Wiki service by customers. Scope All Perfect Wiki personnel, contractors, and customers. Acceptable use — Perfect Wiki personnel Use company-issued credentials and SaaS accounts only for legitimate business purposes. Protect credentials; do not share account passwords or session tokens. Use MFA on all accounts that support it. Do not store customer data on personal devices outside company-approved SaaS. Do not bypass security controls (firewalls, role checks, code review) without explicit, documented authorization. Do not install unapproved software on workstations that have access to production credentials. Report suspected security incidents to [email protected] mailto:[email protected] immediately. Acceptable use — customers Customers and their end-users agree to use Perfect Wiki in accordance with the Terms of Service https://perfectwikiforteams.com/terms/ and applicable law. Prohibited

Purpose Define what Perfect Wiki logs, how those logs are protected and retained, and how they are monitored to detect and respond to security and availability events. Scope Application logs, request logs, audit events of user actions, infrastructure logs from Google Cloud, and error / performance telemetry from Sentry. What is logged HTTP request logs: Source IP, method, URL, status code, response time, user agent — emitted by every API request. Application audit events: Page create/update/delete, page view, comment, search query, bot query, publish/unpublish — each tagged with organization, channel, page, author, timestamp. Authentication events: Sign-in attempts, session creation, session deletion. Error events: Unhandled exceptions, security-relevant errors (auth failures, validation failures, rate-limit hits) captured in Sentry with PII minimization. Scheduled job check-ins: Daily reports, weekly backups, page-updates notifications, stale-org cleanup — each emits a Sentry check-in that alerts on failure.

Purpose Define how Perfect Wiki identifies, evaluates, treats, and monitors risks to the confidentiality, integrity, and availability of its service and customer data. Scope Information-security and operational risks across people, processes, technology, and third parties involved in delivering the Perfect Wiki service. Risk methodology Likelihood: Rare, Unlikely, Possible, Likely, Almost Certain. Impact: Negligible, Minor, Moderate, Major, Severe — measured against customer data, service availability, finances, and reputation. Risk rating: Combined likelihood × impact, classified Low / Medium / High / Critical. Risk treatment Mitigate: Implement controls that reduce likelihood or impact (default for High and Critical risks). Transfer: Use third-party services with stronger controls, contractual indemnities, or cyber insurance. Avoid: Stop or do not start the activity creating the risk. Accept: Document and approve residual risk with explicit sign-off by the CEO/CTO. Process Risks are identified continuously by

Purpose Define how Perfect Wiki identifies, evaluates, prioritizes, and remediates security vulnerabilities across its application code, dependencies, and infrastructure. Scope The Perfect Wiki application, its dependencies (npm packages, base container images, OS packages), its cloud infrastructure, and any externally reported security issues. Sources of vulnerability intelligence Automated dependency advisories via npm audit. Base-image and OS-package advisories from the upstream maintainer and Google Cloud. Sentry error monitoring (surfacing exploit attempts and security-relevant failures). Externally reported issues via [email protected] mailto:[email protected] per the Vulnerability Disclosure page. Vendor security advisories from sub-processors. Severity & remediation SLA Severity is assigned using CVSS v3.1 and adjusted for exploitability and exposure of Perfect Wiki specifically. Critical (CVSS 9.0–10.0): Patch or mitigate within 7 calendar days. High (7.0–8.9): Within 30 days. Medium (4.0–6.9):

Purpose Document how Perfect Wiki keeps the service running through disruptions and how it recovers when underlying infrastructure or processes fail. Scope The Perfect Wiki SaaS service, its production data, and its core business operations. Recovery objectives Recovery Time Objective (RTO): 24 hours for restoring service availability after a SEV1 outage. Recovery Point Objective (RPO): 24 hours — restoration from the most recent daily backup is acceptable as a worst case. Resilience controls Managed cloud services. Production runs on Google Cloud managed services (Firestore, Cloud Storage, Pub/Sub) that provide multi-zone redundancy within each region. Stateless application servers. Containers can be redeployed quickly from the latest image; configuration is held in environment variables provisioned outside the image. Edge protection. Cloudflare provides TLS termination and DDoS protection. Daily encrypted backups of customer data with up to 60-day retention. Backups of high-value (Enterprise / Ultimate) channels

Purpose Define how Perfect Wiki classifies data by sensitivity, how long it is retained, and how it is securely deleted at end-of-life or on customer request. Scope All data stored or processed by Perfect Wiki, including customer content, customer account data, operational logs, backups, and analytics events. Data classification Restricted (customer content): Wiki page bodies, uploaded files, comments, chat queries, search history. Encrypted in transit and at rest; visible only to authorized members of the customer's organization and to a small list of Authorized Personnel for support purposes. Confidential (customer account data): User name, email, role, organization name, billing identifiers, integration tokens. Encrypted in transit and at rest; integration tokens additionally encrypted at the application layer. Internal (operational data): Application logs, error traces (Sentry), product analytics events (PostHog), backup files. Stored in restricted systems and retained per the schedule below. Public: Documentation,

Purpose Define how cryptography is used and how encryption keys are managed across the Perfect Wiki service to protect data confidentiality and integrity. Scope Applies to all cryptographic operations on Perfect Wiki systems, including data-in-transit, data-at-rest, application-layer secret encryption, and authentication tokens. Policy — algorithms and protocols Data in transit: TLS 1.2 minimum, TLS 1.3 preferred, with cipher suites supporting perfect forward secrecy. Insecure protocols (SSLv2/3, TLS 1.0/1.1) are disabled at the edge. Data at rest: AES-256 full-disk encryption is applied by Google Cloud to all storage holding customer data (Firestore, Cloud Storage, Compute Engine disks). Application-layer secrets: Integration tokens and other sensitive values are encrypted with AES-256-GCM using a 32-byte key derived from the service's master encryption secret, with a unique 16-byte IV per ciphertext and authenticated tags verified on decrypt. Random material: Generated using cryptographically secure random number

Purpose Define how identities are managed and how access to Perfect Wiki systems and customer data is provisioned, authenticated, authorized, reviewed, and revoked. Scope Applies to all Perfect Wiki personnel, contractors, customer end-users, and integrations. Policy — end users (customers) End-user authentication is supported via Microsoft Entra SSO, Google Workspace SSO, and passwordless email one-time code. No passwords are stored by Perfect Wiki. Multi-factor authentication is inherited from the customer's identity provider. Customers are responsible for enforcing MFA on Microsoft or Google for their users. For Microsoft Entra logins, the user's email must belong to one of the organization's verified domains (anti-nOAuth-abuse check). Role-based access control is enforced server-side on every API endpoint via middleware. Roles include Admin, Editor, and Viewer. The least-privilege principle is applied. Customer admins are responsible for inviting, removing, and reviewing access of users within their organization.

Purpose This policy establishes Perfect Wiki's commitment to protecting the confidentiality, integrity, and availability of customer data and company information assets. It is the top-level policy from which all other security policies derive. Scope Applies to all systems, services, employees, contractors, and third parties that store, process, or transmit Perfect Wiki information. Customer data is covered by every clause of this policy by default. Policy Information security is owned and sponsored by the CEO/CTO and reviewed at least annually. Customer data is encrypted in transit (TLS 1.2+) and at rest (AES-256). Access to production systems and customer data is granted on a least-privilege, need-to-know basis and is reviewed periodically. Authorized personnel with production access undergo a background check and sign confidentiality / non-disclosure terms before access is granted. Production, staging, and development environments are physically and logically separated. Production data is never used in non-production