Security & Trust Statement

Effective Date: September 8, 2026 Last Updated: September 28, 2026

1. Trust Is Part of the Product

Phillforce exists to help businesses make better customer acquisition decisions from evidence. For that intelligence to be useful, customers need to be able to trust how their information is handled. Phillforce, Inc. (“Phillforce,” “we,” “our,” or “us”) takes the security, confidentiality, integrity, and responsible handling of customer information seriously. We design our technology, operational practices, and development processes with the objective of protecting customer accounts, business information, commercial evidence, and the infrastructure that supports Phillforce. Security is not treated as a one-time feature. It is an ongoing responsibility that requires continued review, monitoring, testing, improvement, and appropriate response as technology and threats evolve.

2. Who We Are

Phillforce is operated by: Phillforce, Inc. 8 Wading Bird Loop Blythewood, SC 29016 United States Website: phillforce.com Security enquiries: security@phillforce.com Privacy enquiries: privacy@phillforce.com Legal enquiries: legal@phillforce.com General enquiries: philip@phillforce.com

3. Purpose of This Statement

This Security & Trust Statement provides a high-level overview of how Phillforce approaches the protection of its customers, systems, and information. It is intentionally written for customers and the public. It does not disclose detailed internal security architecture, vulnerabilities, access paths, credentials, defensive thresholds, internal network information, administrative configurations, incident-response procedures, or other security-sensitive information. Those details are maintained confidentially.

4. Our Security Principles

Phillforce's security approach is guided by several core principles.

Protect Access

Only authorized people and systems should be able to access protected information.

Protect Customer Boundaries

One customer's private business information should not be available to another customer merely because both use Phillforce.

Minimize Information

We aim to collect, process, and retain information that serves a legitimate product, operational, security, legal, or contractual purpose.

Design Security Into the Product

Security should be considered during product design and development rather than added only after a feature has been released.

Assume External Content Is Untrusted

Information collected from websites and external systems is treated as data to be analyzed, not as trusted instructions to Phillforce systems.

Verify Before Trusting

Authorization, identity, data provenance, and system boundaries matter.

Learn and Improve

Security threats evolve, and our controls must evolve with them.

5. Customer Information

Phillforce may process different types of information depending on how a customer uses the service. This may include:

• account information;
• profile information;
• company information;
• customer acquisition evidence;
• funnel information;
• diagnostic history;
• Ask Phill conversations;
• reports;
• connected information where integrations are used;
• technical and security information.

Some of this information may be commercially confidential even when it is not personal information. Phillforce treats private customer business evidence as information that deserves appropriate protection.

6. Customer Data Isolation

Customer isolation is an important part of the Phillforce architecture. Our systems are designed so that users should only be able to access information they are authorized to access. This includes appropriate boundaries around:

• accounts;
• companies;
• workspaces;
• diagnoses;
• business evidence;
• reports;
• Ask Phill information;
• integrations;
• other protected customer information.

Phillforce does not intentionally expose one customer's private commercial information to another customer.

7. Authentication

Phillforce uses authentication mechanisms designed to help confirm that users accessing protected areas are authorized. Depending on the available functionality, authentication may include:

• email and password;
• Google authentication;
• LinkedIn authentication;
• email verification;
• account recovery;
• secure session management;
• periodic email-based step-up verification for protected access where required.

Phillforce may require a fresh one-time email link or code before protected access is renewed or before a sensitive account action is completed. Authentication methods may evolve as the platform develops.

8. Password Protection

Where Phillforce supports password-based authentication, passwords should be handled using appropriate security practices. Phillforce does not intend to store user passwords in readable plain text. Customers are responsible for selecting appropriate passwords and protecting their credentials. Users should not reuse important passwords across unrelated services.

9. Third-Party Authentication

Phillforce may allow users to authenticate through services such as Google or LinkedIn. In these cases, authentication is performed through the applicable provider using supported authorization mechanisms. Phillforce does not receive the user's Google or LinkedIn password. We aim to request only the permissions reasonably necessary for the applicable functionality.

10. Account Security

Phillforce may use controls designed to reduce risks such as:

• unauthorized login;
• credential abuse;
• suspicious account activity;
• session misuse;
• unauthorized account changes.

Sensitive account actions may require additional verification. Examples may include:

• changing an email address;
• changing authentication methods;
• connecting or disconnecting providers;
• deleting an account;
• changing other security-sensitive settings.

11. Authorization

Authentication answers the question: Who are you? Authorization answers: What are you allowed to access? Phillforce treats both as important. Protected product functionality is designed to perform appropriate authorization checks before providing access to customer information or sensitive actions. Simply knowing or manipulating an identifier should not provide legitimate access to another customer's information.

12. Access Control

Access to systems and customer information should be limited according to legitimate business and operational needs. Phillforce may use access-control measures designed around principles such as:

• least privilege;
• role-appropriate access;
• authentication;
• authorization;
• separation of customer information;
• restricted administrative access.

Access requirements may be reviewed as roles and systems change.

13. Administrative Access

Access to administrative systems can create elevated security risks. Phillforce therefore aims to restrict administrative access to individuals who require it for legitimate operational purposes. Where appropriate, stronger authentication, additional controls, logging, or other safeguards may be applied to administrative access. Detailed administrative architecture is not publicly disclosed.

14. Data in Transit

Phillforce uses secure communication technologies where appropriate to help protect information transmitted between users, browsers, applications, and supporting services. Modern encrypted transport technologies are used where supported and appropriate. Customers should also ensure they access Phillforce through legitimate secure domains and maintain reasonably secure networks and devices.

15. Data Storage

Phillforce seeks to protect stored information through appropriate technical and organizational measures. The precise protections may depend on:

• the type of information;
• where it is stored;
• the systems processing it;
• applicable infrastructure capabilities;
• sensitivity;
• legal requirements.

We do not publicly disclose detailed storage architecture or security configurations.

16. Encryption

Encryption may form part of Phillforce's broader security approach where appropriate and supported by the relevant systems and service providers. Phillforce does not publish cryptographic keys, detailed key-management architecture, secret-management procedures, encryption configurations, or other information that could undermine security.

17. Secure Software Development

Phillforce aims to consider security throughout the software-development lifecycle. Depending on the feature and level of risk, this may include attention to:

• authentication;
• authorization;
• input validation;
• output handling;
• secure database access;
• access controls;
• dependency security;
• API security;
• session security;
• error handling;
• secrets management;
• customer isolation;
• security testing.

Security considerations should form part of development and review rather than being treated only as a post-launch issue.

18. AI-Assisted Development

Phillforce may use artificial intelligence to assist with software development. AI-generated code is not automatically assumed to be secure simply because it works. Code produced or modified with AI assistance should be subject to appropriate review, testing, and validation before being relied upon in production. AI development assistance does not remove the responsibility to maintain secure engineering practices.

19. Application Security

Phillforce seeks to reduce common application-security risks through appropriate engineering and operational practices. Depending on the relevant system, protections may address risks involving:

• unauthorized access;
• injection attacks;
• cross-site scripting;
• cross-site request attacks;
• insecure direct object references;
• privilege escalation;
• authentication weaknesses;
• authorization failures;
• insecure configuration;
• exposed secrets;
• abuse of APIs;
• other application-security risks.

Detailed defensive implementations remain confidential.

20. API Security

Where Phillforce provides or uses application programming interfaces, access should be protected according to the nature of the endpoint and information involved. API protections may include controls relating to:

• authentication;
• authorization;
• validation;
• rate limiting;
• logging;
• abuse prevention;
• permissions.

Access to an API does not create permission to access information outside the user's authorized scope.

21. Rate Limiting and Abuse Protection

Phillforce may use measures designed to protect the service against abuse or unreasonable automated activity. These protections may apply to areas such as:

• login;
• account creation;
• Ask Phill;
• website analysis;
• APIs;
• diagnostics;
• reports;
• other computationally intensive functionality.

We do not publicly disclose exact security thresholds or defensive limits.

22. Website Analysis Security

Website analysis is an important part of Phillforce Customer Acquisition Intelligence. However, allowing a platform to retrieve external URLs requires careful security controls. Phillforce designs its website-analysis systems with the objective of analyzing legitimate public business information while reducing the risk that the functionality could be misused to access private or sensitive infrastructure. The service is not intended to provide access to:

• private networks;
• internal systems;
• authenticated resources without permission;
• cloud metadata services;
• administrative infrastructure;
• other non-public resources.

Detailed crawler protections are confidential.

23. External Content Is Treated as Untrusted

Websites analyzed by Phillforce may contain arbitrary external content. Phillforce does not assume that instructions found inside an external website should control the operation of Phillforce. External website content is treated as information to be analyzed. It should not be treated as trusted system instructions. This principle is particularly important where artificial intelligence is involved.

24. Prompt Injection and AI Security

AI systems may face attempts to manipulate their behavior through malicious or misleading instructions. Phillforce recognizes prompt injection and similar AI-specific security risks. Our objective is to maintain boundaries between:

• customer instructions;
• external evidence;
• internal system instructions;
• authorization controls;
• private information.

No AI system can guarantee prevention of every conceivable manipulation attempt. Phillforce therefore treats AI security as an evolving engineering and operational responsibility.

25. Ask Phill and Customer Information

Ask Phill is intended to operate within the customer's authorized information context. A user should not be able to obtain another customer's private information merely by asking Ask Phill for it. Authorization boundaries should remain applicable even when information is being interpreted through artificial intelligence. Attempts to bypass those boundaries are prohibited under the Phillforce Acceptable Use Policy.

26. AI Providers

Phillforce may rely on approved third-party AI infrastructure or technology providers. Where customer information is processed through such providers, Phillforce seeks to use appropriate contractual, privacy, security, and technical arrangements consistent with the service being provided. The providers supporting Phillforce may change as technology develops. Our Privacy Policy contains additional information about processing and third-party providers.

27. Customer Information and AI Training

Phillforce does not intentionally expose one customer's private commercial evidence to another customer. Phillforce also does not intend to use customers' private commercial evidence to train general-purpose shared models in a manner that makes the information available to other customers, except where the customer has expressly agreed or where information has been appropriately de-identified, aggregated, or otherwise processed in accordance with applicable law and agreement. Our technical implementation and providers should be maintained consistently with these commitments.

28. Monitoring

Phillforce may monitor system activity to support purposes including:

• security;
• fraud prevention;
• abuse detection;
• reliability;
• incident investigation;
• troubleshooting;
• performance.

Monitoring should be proportionate to legitimate operational and security requirements. Phillforce does not intend to monitor customer activity merely for unnecessary surveillance.

29. Security Logging

Security-relevant activity may be logged where appropriate. Logs can help Phillforce:

• detect suspicious activity;
• investigate incidents;
• understand failures;
• prevent abuse;
• protect accounts;
• maintain operational reliability.

Phillforce aims to avoid unnecessarily including sensitive information in logs. Detailed logging configurations and security detection rules are confidential.

30. Vulnerability Management

Software vulnerabilities can occur in any modern technology environment. Phillforce seeks to maintain processes for identifying, evaluating, prioritizing, and addressing relevant vulnerabilities. This may include:

• dependency review;
• security testing;
• vulnerability reports;
• software updates;
• patching;
• security research;
• provider notifications.

Remediation priority may depend on severity, exploitability, exposure, customer impact, and other risk factors.

31. Software and Dependency Updates

Phillforce may rely on software libraries, frameworks, plugins, infrastructure, and third-party technologies. These technologies evolve and may occasionally contain vulnerabilities. Phillforce seeks to maintain relevant software and dependencies appropriately and evaluate important updates based on security and operational risk.

32. Security Testing

Phillforce may perform security testing appropriate to its systems and stage of development. This may include:

• code review;
• automated testing;
• manual testing;
• authorization testing;
• authentication testing;
• configuration review;
• vulnerability assessment;
• application testing.

The nature and frequency of testing may evolve as Phillforce grows.

33. Responsible Security Research

Phillforce welcomes responsible reports from security researchers. If you believe you have discovered a vulnerability, please contact: security@phillforce.com and follow the Phillforce Responsible Vulnerability Disclosure Policy. Researchers should not intentionally:

• access customer information;
• destroy information;
• disrupt services;
• conduct denial-of-service attacks;
• perform social engineering;
• publicly disclose an unresolved vulnerability in a manner that creates unnecessary risk.

34. Incident Response

Phillforce maintains or seeks to maintain processes for responding to suspected security incidents. Depending on the circumstances, response activities may include:

• identifying the issue;
• containing the risk;
• investigating the cause;
• protecting affected systems;
• restoring operations;
• evaluating affected information;
• implementing corrective actions;
• notifying appropriate parties where required.

Our detailed incident-response procedures are confidential.

35. Security Incident Notifications

If a security incident results in a notification obligation under applicable law or contract, Phillforce intends to provide the required notification to affected customers, individuals, regulators, or other parties within the legally applicable timeframe. The nature of any notification will depend on the circumstances and applicable legal requirements.

36. Backups

Phillforce may maintain backups of important systems and information as part of resilience and recovery planning. Backups may support recovery from circumstances such as:

• technical failure;
• accidental deletion;
• infrastructure failure;
• security incidents;
• disaster events.

Backup architecture, schedules, locations, and detailed restoration procedures are not publicly disclosed for security reasons.

37. Recovery and Resilience

Phillforce seeks to design its systems so that important services can be restored following significant disruption. Recovery planning may address areas such as:

• application availability;
• data restoration;
• infrastructure recovery;
• critical providers;
• operational continuity.

Recovery capabilities may evolve as the company and platform grow.

38. Business Continuity

Phillforce relies on technology, infrastructure, service providers, and people. Unexpected disruptions may occur. We seek to maintain reasonable business continuity practices appropriate to the nature and maturity of the company. No internet service can guarantee uninterrupted operation under every possible circumstance.

39. Third-Party Service Providers

Phillforce may rely on trusted service providers to support operations. These may include providers of:

• hosting;
• cloud infrastructure;
• artificial intelligence;
• authentication;
• email;
• monitoring;
• analytics;
• payments;
• communications;
• other technology services.

We seek to consider relevant privacy, security, reliability, and contractual factors when selecting providers that process important customer information.

40. Subprocessors

Where Phillforce uses subprocessors to process personal information on behalf of business customers, applicable contractual and data-protection requirements may apply. Phillforce may maintain a separate Subprocessor List as appropriate. The Subprocessor List should reflect providers actually used by Phillforce rather than hypothetical providers.

41. Payment Security

Phillforce may use third-party payment processors to handle customer payments. Where our payment architecture allows, full payment-card details are intended to be processed directly by the applicable payment processor rather than stored by Phillforce. Payment processors operate their own security infrastructure and may be subject to additional payment-industry requirements. Phillforce does not claim a payment-security certification simply because a third-party processor has one.

42. Data Minimization

Collecting less unnecessary information can reduce security risk. Phillforce seeks to avoid requesting highly sensitive personal information that is not reasonably required for customer acquisition intelligence. Customers should not submit unnecessary information such as:

• Social Security numbers;
• passwords for third-party services;
• private banking credentials;
• government identification records;
• unnecessary health records;
• other unrelated highly sensitive information.

43. Data Retention

Information should not be retained indefinitely without reason. Phillforce's retention practices may consider:

• service requirements;
• account activity;
• contractual requirements;
• legal obligations;
• security;
• fraud prevention;
• dispute resolution;
• legitimate business needs.

Additional information is provided in our Privacy Policy and Account & Data Deletion Policy.

44. Account and Data Deletion

Customers may request deletion of qualifying personal information or their Phillforce account through the available Privacy & Data controls. Account deletion is treated as a sensitive action and may require fresh identity verification. Where an account still owns a shared workspace, ownership may need to be transferred before deletion can be completed so workspace records and access responsibilities remain coherent. Deletion from active systems does not necessarily mean immediate removal from every protected backup. Some information may also need to be retained for legal, financial, security, fraud-prevention, or dispute-related purposes. Phillforce's Account & Data Deletion Policy provides additional information.

45. Employee and Contractor Access

People working for or with Phillforce may require access to certain systems in order to perform legitimate responsibilities. Access should be appropriate to role and operational need. Where appropriate, individuals with access to confidential information may be subject to obligations relating to:

• confidentiality;
• appropriate use;
• access control;
• security;
• privacy.

Access should be removed or adjusted when it is no longer reasonably necessary.

46. Confidentiality

Private customer commercial evidence may include sensitive business information such as:

• acquisition metrics;
• revenue-related information;
• funnels;
• customer acquisition costs;
• commercial strategy;
• sales information;
• internal performance information.

Phillforce recognizes that such information may have substantial commercial value even if it is not legally classified as personal information. We seek to treat confidential customer information accordingly.

47. Internal Security Information

Some Phillforce information is intentionally not public. This may include:

• detailed architecture;
• vulnerability findings;
• penetration-test results;
• authentication internals;
• infrastructure topology;
• administrative routes;
• secret-management architecture;
• internal security procedures;
• exact monitoring rules;
• access-control details;
• internal incident-response procedures;
• exact rate limits;
• security thresholds;
• backup locations.

Keeping such information confidential is an additional security measure. Confidentiality does not replace strong technical security controls.

48. Privacy and Security

Privacy and security are related but distinct. Security helps protect information. Privacy governs how information is collected, used, disclosed, retained, and subject to individual rights. Phillforce's processing of personal information is explained in our Privacy Policy. Privacy rights are further described in our Data Rights Request Policy.

49. Access to Customer Support

Phillforce support personnel may occasionally need access to information necessary to investigate a customer-reported issue. Where such access is required, it should be limited to information reasonably relevant to the support, troubleshooting, security, or operational purpose. Customers should avoid including unnecessary sensitive information in support requests.

50. Customer Responsibilities

Security is a shared responsibility. Phillforce protects the platform, but customers also play an important role in protecting their accounts. Customers should:

• use strong passwords;
• protect authentication methods;
• keep devices secure;
• avoid sharing credentials;
• remove unauthorized users;
• review connected accounts;
• report suspicious activity;
• maintain secure email accounts;
• protect downloaded reports and exported information.

A secure platform cannot fully protect a customer account if the customer's own credentials or device are compromised.

51. Reporting Suspicious Account Activity

If you believe your Phillforce account has been accessed without authorization, contact: security@phillforce.com as soon as reasonably possible. Include enough information for us to understand the issue, but do not send passwords or authentication credentials by email.

52. Connected Intelligence

Phillforce may allow customers to connect external platforms and business systems. Connected Intelligence may involve authorization to retrieve information from third-party services. Where such integrations are available, Phillforce seeks to use:

• appropriate authorization mechanisms;
• limited requested permissions;
• appropriate credential or token handling;
• customer-controlled connection management.

Customers should only connect systems they are authorized to access.

53. Integration Permissions

Where technically possible, Phillforce aims to request permissions proportionate to the feature being provided. We do not want to request unnecessary access merely because a third-party platform makes that access available. Where a future feature requires additional access, customers should receive appropriate information about what the integration needs and why.

54. Disconnecting Integrations

Where supported, customers may be able to disconnect integrations through:

• Phillforce settings;
• the third-party provider;
• another applicable account-management mechanism.

Disconnecting a service may prevent future retrieval of information. It does not necessarily delete information already lawfully processed or retained by Phillforce.

55. Authentication Providers

Google, LinkedIn, and other authentication providers maintain their own security systems and policies. Phillforce does not control the independent security practices of those providers. Customers should maintain appropriate security on their third-party identity accounts.

56. Security and Product Changes

Phillforce will continue to evolve. New features may introduce new security considerations. Security review should therefore accompany significant functionality such as:

• new authentication methods;
• Connected Intelligence;
• APIs;
• team workspaces;
• AI capabilities;
• new evidence sources;
• new reporting;
• new third-party integrations.

Security requirements should evolve with the product.

57. No Absolute Security Guarantee

No company operating an internet-connected service can guarantee that a security incident will never occur. Phillforce therefore does not promise absolute security. Instead, we commit to taking security seriously, maintaining reasonable safeguards, continuously improving our security posture, and responding appropriately when credible security concerns arise. Statements concerning security should be understood in that context.

58. No Implied Certification

Unless Phillforce expressly states otherwise in an official current document, this Security & Trust Statement does not mean Phillforce has obtained a specific independent certification or audit. For example, Phillforce should not be assumed to hold certifications such as:

• SOC 2;
• ISO 27001;
• PCI DSS certification;
• FedRAMP;
• HITRUST;

unless Phillforce expressly confirms the applicable certification. We believe customers should receive accurate security information rather than implied certifications that have not been earned.

59. Future Security Certifications

As Phillforce grows and customer requirements evolve, we may pursue appropriate security audits, assessments, certifications, or assurance programs. Our priorities may depend on:

• customer demand;
• regulatory requirements;
• enterprise requirements;
• platform maturity;
• risk;
• operational scale.

Any completed certification should be communicated accurately and within its actual scope.

60. Security Documentation for Business Customers

Certain business or enterprise customers may request additional security information as part of vendor review. Phillforce may provide appropriate information through a controlled process where commercially reasonable. Access to detailed security information may require:

• confidentiality obligations;
• a nondisclosure agreement;
• appropriate customer status;
• another controlled review process.

We reserve the right to withhold information that would create unnecessary security risk.

61. Responsible Vulnerability Disclosure

If you believe you have discovered a security vulnerability involving Phillforce, please report it responsibly. Contact: security@phillforce.com Please include information such as:

• the affected product or page;
• a clear description of the issue;
• reasonable reproduction steps;
• potential impact;
• supporting evidence where safe.

Do not include customer information obtained without authorization. Additional requirements are contained in our Responsible Vulnerability Disclosure Policy.

62. Security Questions From Customers

Customers may contact us with reasonable questions concerning Phillforce security. Security enquiries should be directed to: security@phillforce.com We may not be able to answer questions that require disclosure of confidential defensive information. Where possible, we will seek to provide meaningful information without weakening security.

63. Changes to This Security & Trust Statement

Phillforce may update this Statement as:

• our platform evolves;
• our infrastructure changes;
• new security practices are introduced;
• new integrations are launched;
• new threats emerge;
• applicable laws change;
• independent assessments are completed.

The “Last Updated” date at the top will identify the current version.

64. Contact Phillforce

Questions about security, privacy, or trust may be directed to: Phillforce, Inc. 8 Wading Bird Loop Blythewood, SC 29016 United States Security: security@phillforce.com Privacy: privacy@phillforce.com Legal: legal@phillforce.com General enquiries: philip@phillforce.com Website: phillforce.com

Phillforce, Inc. Clarity before activity.