Security Policy
Effective date: 6 November 2026
1. Purpose Lighthouse treats protection of account, project, commercial and personal information as part of operating the service. Security responsibilities are shared with users and relevant providers. No service is immune from all risk. This policy explains reporting and user responsibilities. It is not a claim of ISO certification, SOC reporting, end-to-end encryption, a particular data-residency architecture or guaranteed uptime. Specific enterprise commitments apply only when agreed and supported by evidence.
2. Protecting your account Keep OTPs, passwords and recovery information private. Use only authorised devices and user roles, review business-account access, and remove staff who no longer need access. A Lighthouse representative should not ask you to disclose an OTP. Verify payment recipient details against the accepted order and independently verify an unexpected change. Report suspected account takeover, phishing or altered payment instructions promptly.
3. Reporting a vulnerability or incident Use [CONFIRM monitored security email/form]. Provide a concise description, affected service/URL, approximate discovery time, steps sufficient to reproduce safely and any minimal non-sensitive evidence. Do not send passwords, production secrets, bulk personal data or complete customer files. If sensitive evidence is needed, request a secure channel. An urgent report must have a staffed escalation route; an unmonitored marketing inbox is unsuitable.
4. Responsible research boundaries Do not access another user’s data, disrupt the service, conduct denial-of-service testing, use social engineering, deploy malware or continue exploiting a discovered issue. Stop at the minimum evidence necessary and report it. This policy does not itself authorise penetration testing, grant unrestricted legal immunity or promise a bounty. Authorised testing requires an agreed scope and conditions. Lighthouse will assess good-faith reports fairly and seek coordinated remediation.
5. Response and communication We assess severity, contain risk, investigate and take corrective action. We notify customers, affected individuals and authorities where required by law or an applicable agreement. Different notification duties can run concurrently.
A notification will distinguish confirmed facts from ongoing investigation and give relevant protective steps. We do not wait for a perfect root-cause report before meeting an applicable reporting deadline.
6. Providers and enterprise information Security-related providers must receive only necessary access and appropriate contractual obligations. Enterprise customers may request available evidence under confidentiality, subject to protection of other customers and sensitive security details. Internal security configuration, response plans and vulnerability details must not be published in the public Legal Center merely because they are tabs in the authoring document.
Publication check Confirm reporting contacts, escalation ownership, actual safeguards and public claims. The Security Addendum, Information Security Addendum and Incident Response Schedule contain proposed contractual and internal controls that must be validated before adoption.
7. Account and transaction protection Use unique credentials and supported strong authentication. Never disclose an OTP, password, recovery code or payment PIN to a person claiming to be Lighthouse support. Verify payment-recipient changes independently and report suspected account takeover promptly. For business accounts, restrict administrators to authorised personnel, remove departing users and periodically review access. An employee’s departure must not leave ownership of the company profile dependent on a personal telephone number. Recovery requests require proportionate evidence and may temporarily limit sensitive actions.
8. Safe uploads and sensitive project information Do not include unnecessary identity documents, credentials, access codes, detailed security layouts or precise residential information in public portfolios. File names and embedded metadata may reveal information even when it is not visible in the image. Review material before sharing externally. Private plans, quotes and enterprise documents require access controls through processing, search indexes, previews and exports. An unlisted link is not necessarily confidential. Share links should have the actual restrictions advertised to users and should be revoked when no longer required.
9. Vulnerability reporting Report a suspected vulnerability through [CONFIRM SECURITY REPORTING CHANNEL], including the affected URL or feature, a clear reproduction description and minimal evidence. Stop testing if it exposes another person’s data, affects availability or risks physical harm. Do not copy more information than necessary to demonstrate the issue.
This reporting route is not blanket permission for intrusive testing, social engineering, denial-of-service, credential attacks or access to third-party systems. Any authorised testing scope or safe-harbour commitment must be separately published and approved. No bug-bounty payment is promised unless a programme expressly states one. We will triage a good-faith report, seek clarification where needed and coordinate remediation and disclosure where appropriate. Do not publish exploit details that unnecessarily expose users before reasonable coordination; lawful reporting and protected disclosures remain unaffected.
10. Incident handling and communications When an incident is suspected, Lighthouse may revoke sessions or keys, suspend an affected feature, preserve logs, restrict downloads and require credential resets. Such action should be proportionate to the risk. Users should follow authenticated notices and avoid links in unverified messages. We assess notifications under applicable Indian and destination-country rules and customer contracts. A preliminary notification may precede a complete investigation. We will communicate confirmed information, protective steps and updates without presenting speculation as established fact.
11. Security claims and customer boundaries Encryption, backups, testing and access-control claims must describe implemented controls and their actual coverage. We do not claim ISO certification, SOC reports, PCI compliance, fixed recovery times or a specific data region without evidence. A processor’s certification does not automatically certify Lighthouse. A business customer remains responsible for its user permissions, lawful inputs, endpoint security and supported integrations; Lighthouse remains responsible for its own service controls. Neither party may use this division to avoid a specific obligation it has undertaken.
12. Cross-border services An international release requires assessment of data locations, remote support, vendor access, incident notification and local security requirements. The Security Addendum and Information Security Addendum identify proposed contractual commitments; they become binding only when adopted in the applicable agreement. This public policy must reflect actual practice before release.
13. Account recovery and disputed control A user who loses access should use the published recovery channel and provide proportionate evidence of account control. Lighthouse will not transfer an organisation's account solely because a person knows a public phone number or supplies a logo. Where administrators disagree, access to sensitive functions may be restricted while authority is assessed. Recovery must consider the risk of a compromised email or recycled phone number. The process should protect existing users and relevant business records without requiring
disclosure of unnecessary identity material. A support agent must not ask for an OTP or password intended for the user's own login.
14. Fraudulent payment and impersonation reports Report unexpected requests to change bank details, pay a new beneficiary or install remote-access software. Preserve the message and transaction reference where safe. Do not assume a message is genuine because it uses a Lighthouse logo or quotes an order number. Lighthouse may contact affected users through verified channels and restrict compromised accounts. Such assistance does not guarantee recovery of money already transferred to an unrelated party. Users should also contact their payment provider and appropriate authorities promptly where fraud is suspected.
15. Authorised security research Research must be limited to systems the researcher is authorised to test and conducted in a manner that avoids harm. Do not access another user's records, extract production datasets, alter orders, deploy persistence, perform destructive testing or disrupt service. If unexpected sensitive data appears, stop access and report the minimum necessary evidence through the security channel. This policy does not grant authority over a third-party provider's systems, promise a bounty or create immunity from law. Any specific testing authorisation must identify scope, methods and contacts. Lighthouse will assess good-faith reports fairly and distinguish responsible reporting from exploitation or extortion.
16. Report handling and coordinated disclosure A useful report includes the affected service, steps sufficient to reproduce safely, observed impact, relevant timestamps and a secure contact. Avoid placing exploit details or personal data in public comments. Lighthouse may request clarification and will assess remediation according to severity and exploitability. Publication timing should be coordinated where possible to reduce risk to users. Coordination must not require indefinite silence about an unresolved material issue or obstruct a lawful regulatory report. Lighthouse must not describe a vulnerability as resolved until the relevant correction has been checked.
17. User and platform responsibilities Users must secure their own devices, manage authorised staff access and review unusual activity. Lighthouse remains responsible for the platform controls it operates. Neither party's responsibilities excuse the other's own failure. Customer-selected integrations may create additional access paths. Permissions should be limited and revoked when no longer required. A third-party app's presence in an integration directory does not mean Lighthouse has certified every use or security property.
18. Communication after an incident Where notice is required or appropriate, Lighthouse will explain known facts, affected information or functions, protective steps and a contact route without exposing details that create further risk. Early notices may be supplemented as the investigation develops. A security incident, service outage and personal-data breach may overlap but are not identical. Each applicable notification duty must be assessed separately. Public statements must distinguish confirmed findings from matters still under investigation and must not promise that no data was affected without sufficient evidence.