Security Policy

Last Updated: August 8, 2025

ARTICLE I: PURPOSE AND SCOPE

1.1 Objective

This Security Document describes the technical, administrative, and organizational safeguards that Impulsum Me LLC (“Impulsum,” “we,” “our,” or “us”) applies in order to protect the confidentiality, integrity, and availability of customer data processed by the Impulsum platform located at impulsum.me (the “Platform”). It also explains the responsibilities of customers, partners, and employees in supporting those safeguards.

1.2 Covered Services

The protections in this document apply to the Impulsum web application, backend services, APIs, command line utilities, and any future mobile or desktop clients that interface with the same backend. They also apply to all integrations that synchronize data between Impulsum and third-party project-management systems, currently Jira and, prospectively, Trello, Asana, ClickUp, Monday.com, and any other third-party project management systems integrated via API or OAuth, such as but not limited to Jira, Trello, Asana, ClickUp, and Monday.com.

1.3 Relationship to Other Policies

This Security Document operates in concert with, but is distinct from, our Privacy Policy, Acceptable Use Policy, Terms and Conditions, and internal Employee Handbook. Where conflicts appear, the stricter control prevails unless overridden by applicable law.

1.4 Nature of Document and Binding Status

This Security Document is provided solely for informational purposes and describes Impulsum’s current security practices. It does not create any legally binding obligations or contractual guarantees unless explicitly incorporated into a separate, duly executed agreement (e.g., Data Processing Addendum or Enterprise Master Agreement). In the event of any conflict between this Security Document and the Terms and Conditions, the Terms and Conditions shall control, unless otherwise contractually agreed. This document describes current practices but is subject to modification in response to evolving threats, changes in technology, or regulatory updates. Nothing in this document shall be construed as a waiver of any disclaimers, limitations of liability, or other protections afforded to Impulsum under the Terms and Conditions.

1.5 No Guarantee of Absolute Security

Although Impulsum applies industry-standard security controls aligned with recognized frameworks, no system is impenetrable. Accordingly, Impulsum does not guarantee absolute protection against all threats or vulnerabilities.

1.6 Customer Responsibilities

Users are responsible for maintaining the security of their own environments, including:

a) Using strong and unique passwords or authentication mechanisms;

b) Keeping API credentials and session tokens confidential;

c) Enabling multi-factor authentication where available;

d) Monitoring account activity and promptly reporting any suspicious behavior;

e) Complying with all applicable third-party service agreements (e.g., Jira, Trello);

f) Ensuring compliance with all applicable API usage rules of third-party integrations (including rate limits, data access restrictions, and attribution requirements);

g) Enabling multi-factor authentication and adhering to usage policies for any connected integrations, including AI providers like OpenAI, Anthropic, or Google Gemini, especially where such integrations provide administrative or project-level data access.

ARTICLE II: GOVERNANCE AND COMPLIANCE

2.1 Security Governance Structure

Impulsum maintains an executive‑level Security Steering Committee chaired by the Chief Information Security Officer and attended by the Chief Executive Officer, Chief Technology Officer, and Legal Counsel. The committee meets at least quarterly to review security metrics, risk assessments, and audit findings.

2.2 Policies and Standards

Formal security policies, including Access Control, Encryption, Change Management, Secure Development, Incident Response, and Vendor Management, are documented, version‑controlled, approved by senior leadership, and reviewed annually. All employees acknowledge these policies upon hire and upon each significant revision.

2.3 Regulatory Alignment

While Impulsum currently processes data primarily from United States‑based customers, we design controls to satisfy a wide range of frameworks and regulations, including SOC 2 Type II, ISO 27001, GDPR, CCPA, CPRA, and the National Institute of Standards and Technology Cybersecurity Framework. Where regional requirements differ, we adopt the strictest applicable safeguard.

2.4 Independent Assessments

We engage accredited third‑party auditors to perform a SOC 2 Type II examination annually. Executive summaries and bridging letters are available under nondisclosure to qualified customers through our Trust Center. We also contract an independent penetration‑testing firm no less than once per calendar year to evaluate application, network, and cloud posture. Identified findings are remediated according to a severity‑based service‑level matrix (critical within thirty days, high within sixty, medium within ninety, and low within one hundred twenty days).

2.5 Risk Management

A formal risk‑management program evaluates threats to assets, the likelihood of exploitation, and potential business impact. Results inform budget allocations, control enhancements, and disaster‑recovery planning.

2.6 Informational Status of Controls

Impulsum maintains policies and controls that reflect our alignment with industry best practices and regulatory standards. However, all such measures are subject to periodic review, continuous improvement, and evolving threat landscapes. This document illustrates those current controls but does not constitute a representation of future capabilities.

2.7 Confidentiality of Security Measures

To protect the integrity of our security infrastructure, certain technical details and configurations are considered Confidential Information and are not disclosed publicly. Any documentation, audit results, or logical diagrams shared with customers are provided under confidentiality restrictions as outlined in our Terms and relevant agreements.

2.8 De-identification Practices

In line with privacy-by-design principles, Impulsum employs de-identification techniques to remove or mask direct and indirect identifiers from customer datasets before using them for internal analytics, security testing, or model evaluation. These measures are designed to ensure that the resulting data cannot reasonably be linked to an individual, and re-identification is prohibited except to validate the effectiveness of the de-identification process.

ARTICLE III: INFRASTRUCTURE SECURITY

3.1 Cloud Hosting Environment

Impulsum is built on Amazon Web Services as its primary infrastructure provider. Core workloads are deployed in three Availability Zones within the AWS US‑East region to ensure fault tolerance. Data residency within the United States is guaranteed unless the customer elects a regional deployment once such feature is generally available.

3.2 Network Segmentation and Firewalls

Production networks are logically segmented from staging and development. Security groups and network access control lists tightly restrict inbound and outbound traffic. Only hardened bastion hosts may initiate administrative sessions, and all such sessions require multi factor authentication and are logged centrally.

3.3 Encryption in Transit

All communications between user endpoints, our servers, and downstream processors occur over Transport Layer Security version 1.2 or higher. Weak cipher suites and deprecated protocols (for example SSLv3) are disabled. Certificate management is fully automated using AWS Certificate Manager.

3.4 Encryption at Rest

Customer data, including backup snapshots, is encrypted at rest using AWS Key Management Service customer managed keys with the Advanced Encryption Standard employing a two‑hundred fifty six‑bit key length. Keys rotate annually or immediately upon suspected compromise.

3.5 Infrastructure Hardening

Operating system images originate from hardened Amazon Linux or Ubuntu LTS baselines, incorporating Center for Internet Security Level 1 benchmarks. Unnecessary packages and services are removed, and a configuration‑management system enforces baseline compliance on launch and continuously thereafter.

3.6 Vulnerability Scanning

External and internal vulnerability scans are conducted on a weekly cadence. Findings are triaged according to CVSS scores and patched under the same service‑level matrix indicated in Clause 2.4.

ARTICLE IV: DATA FLOW AND HANDLING

4.1 Data Classification

We classify data into four categories: Public, Internal, Confidential, and Restricted. Project artifacts synchronized from Jira and other integrations are considered Restricted, triggering the highest level of protection.

4.2 Data Flow Diagram

When a user issues a natural language query, the client transmits the query, relevant project identifiers, and any required context to the Impulsum API endpoint. The backend fetches the latest project data from Jira and any other third-party project management systems integrated via API or OAuth, such as but not limited to Jira, Trello, Asana, ClickUp, and Monday.com, through OAuth-scoped API tokens, enriches that data with predictive features, and packages the resulting prompt for GPT-4 or other configured language models. Model responses are post-processed on our servers then returned to the client over an encrypted channel. A full logical diagram is available upon request.

4.3 Storage Locations

Transactional application data resides in Amazon Relational Database Service. Search indexes operate on Amazon OpenSearch. Audit logs flow to Amazon CloudWatch and are retained for seven years. Cold backups are stored in Amazon Simple Storage Service with cross‑region replication enabled.

4.4 Data Minimization

We store only the data required to deliver contracted functionality. Ephemeral files containing customer project snapshots are deleted within twenty four hours unless analytical caching is explicitly enabled by the customer.

4.5 Data Segregation

Tenant isolation is enforced through unique database schemas keyed to a tenant identifier and through application logic that validates tenant claims at every data boundary.

ARTICLE V: IDENTITY AND ACCESS MANAGEMENT

5.1 Authentication

Customers may authenticate with platform credentials featuring a twelve‑character minimum and complexity engine, or via Single Sign‑On through SAML 2.0 or OpenID Connect. All administrative accounts require multi factor authentication.

5.2 Authorization

Role‑based access control maps to the principle of least privilege. Predefined roles include Owner, Administrator, Manager, and Viewer. Custom roles are available to enterprise customers. Privilege escalation requests are logged and require dual approval.

5.3 Credential Storage

User passwords are hashed with Argon2id configured for ten iterations, eighty megabytes of memory, and four parallel threads. Application secrets such as API tokens are stored in AWS Secrets Manager and rotated at least every ninety days.

5.4 Session Management

JSON Web Tokens signed with RSA‑four thousand ninety six bits represent sessions and expire after sixty minutes of inactivity by default. Refresh tokens are subject to strict origin checks and may be revoked through the Dashboard.

5.5 Employee Access

Only employees assigned to the Engineering or Support teams may access production data, and solely for legitimate business purposes. All access is time‑bound, request‑based, and auto revoked. Audit logs capture the requester, reviewer, purpose, and duration.

ARTICLE VI: APPLICATION SECURITY

6.1 Secure Development Life Cycle

Developers follow an SDLC that embeds security checkpoints at planning, design, implementation, code review, testing, and deployment stages. Threat modeling is mandatory for all new feature epics. Code reviews must be conducted by one author and two approvers, at least one of whom is security trained.

6.2 Dependency Management

A central repository enforces signed commits and provenance attestations for third‑party libraries. Static manifests are scanned daily with tools such as OWASP Dependency‑Check and Snyk. High‑risk dependencies are patched or replaced within thirty days.

6.3 Static and Dynamic Analysis

Statically compiled artifacts undergo analysis by CodeQL on each pull request. A nightly dynamic security testing suite exercises the staging environment using Zed Attack Proxy and custom scenarios covering authentication, injection, and cross‑site scripting.

6.4 Build and Deployment Pipeline

The continuous integration pipeline executes inside isolated AWS CodeBuild containers. Artifacts are signed with SHA‑two hundred fifty six digests and published to Amazon Elastic Container Registry. Only signed artifacts may deploy to production via AWS CodeDeploy with automatic rollback on failed health checks.

6.5 Logging and Monitoring

Structured application logs incorporate unique request identifiers, user identifiers (hashed), and coarse geolocation. Sensitive payloads such as personal data fields are masked. A Security Information and Event Management system ingests logs in near real time and triggers alerts on anomalous patterns.

ARTICLE VII: AI MODEL SECURITY AND DATA GOVERNANCE

7.1 Model Providers

Primary large language model inference is supplied by OpenAI GPT-four hosted in the United States. Secondary providers, evaluated for parity in security posture, include Anthropic Claude and Google Gemini. We maintain zero-retention agreements with all AI model providers, including but not limited to OpenAI, Anthropic, Google Gemini, or equivalents, ensuring no customer data is used for training. We maintain no infrastructure or subprocessors in any jurisdiction subject to data localization requirements that conflict with United States export regulations.

7.2 Zero Retention Agreements

All model providers have executed zero retention contractual riders in which they commit not to store prompt or completion data for longer than thirty days and never to use such data for training or service improvement. These zero-retention agreements are subject to U.S. export law and data locality restrictions, and Impulsum contractually prohibits any use of customer prompt data for training, except where explicitly permitted in writing.

7.3 Prompt Construction

Prompt assembly occurs server side in a stateless microservice. Prompts include only the minimum viable context for accurate predictions. Personally identifiable information is tokenized before transmission whenever feasible.

7.4 Confidential Mode

Enterprise customers may enable Confidential Mode, an enforced privacy feature that prevents any portion of synchronized project data from persisting beyond the immediate session and bypasses analytical caching. Service replicas dedicated to Confidential Mode exclude all logs at the application layer. If a request is ambiguous regarding mode, the system defaults to Confidential Mode. In Confidential Mode, data does not persist beyond the session and helps mitigate bias risks under laws like the Colorado Privacy Act (CPA) by limiting exposure of sensitive prompts to any AI provider (including but not limited to OpenAI, Anthropic, or Google Gemini). For high-sensitivity use cases, including those subject to state-level AI risk management obligations such as the Colorado Artificial Intelligence Act, customers are strongly encouraged to avoid entering sensitive or bias-prone data into prompts, and to operate exclusively in Confidential Mode to reduce risk of inadvertent bias or unintended data persistence.

7.5 Model Fine‑tuning

Fine‑tuning activities use synthetic or fully de‑identified datasets. Customer data is never introduced to fine‑tuning without a separate Data Processing Addendum explicitly permitting such use. Customer data is never used for fine-tuning or model training unless a separate Data Processing Addendum expressly permits such use. Impulsum strongly recommends enabling Confidential Mode in regulated environments to prevent any prompt data from persisting in third-party logs during the temporary retention window.

ARTICLE VIII: SUBPROCESSORS AND THIRD‑PARTY SERVICES

8.1 Classification of Subprocessors

We maintain a published list of authorized subprocessors grouped by data exposure level. Categories are:

a. Sees and Stores Project Data

b. Sees Project Data (Transient)

c. Sees Personal Data Only

d. Sees No Customer Data

8.2 Core Subprocessor Inventory

The current inventory is provided in the table below and is updated at least thirty days before onboarding any new subprocessor that sees or stores project data.

‍

‍

8.3 Diligence and Oversight

Each subprocessor undergoes vendor risk assessment including review of compliance attestations, penetration tests, and contractual commitments to confidentiality, privacy, and incident notification.

8.4 Legal and Contractual Safeguards

All subprocessors that access, store, or process customer or project data are required to execute written agreements containing strict confidentiality, data protection, and breach notification obligations. Impulsum ensures that subprocessors comply with applicable data transfer and localization requirements and are evaluated based on compliance certifications (such as ISO 27001, SOC 2, and PCI DSS), security posture, and contractual enforceability. Where subprocessors provide AI model services (including but not limited to OpenAI, Anthropic, and Google), such subprocessors are contractually required to comply with U.S. export control laws, applicable data locality restrictions, and to honor zero-retention and no-training commitments for customer data unless an explicit, signed Data Processing Addendum permits such use. Retention by such subprocessors, if any, is limited to the temporary operational windows described in our Privacy Policy (currently up to thirty days).

8.5 Integration with Customer Data Sources

Use of third-party project management systems (e.g., Jira, Trello, Asana) via API integrations assumes that the customer holds sufficient rights to authorize Impulsum to access and process such data. Impulsum complies with all applicable API terms and imposes access and storage limits consistent with our internal data-handling protocols.

ARTICLE IX: VULNERABILITY MANAGEMENT AND DISCLOSURE

9.1 Internal Testing

Our Security Engineer conducts monthly manual code reviews and red team exercises targeting business logic flaws.

9.2 External Reporting Channel

Security researchers are encouraged to submit vulnerability reports via https://github.com/impulsum‑security/vuln‑reports. We acknowledge submissions within five business days and provide status updates at least every fourteen days until closure.

9.3 Reward Program

A discretionary bounty may be awarded for valid, original reports that result in code or configuration changes. Scope, rewards, and terms are detailed on the disclosure portal.

9.4 Non Disclosure Period

Researchers must refrain from public disclosure until a fix has been deployed or ninety days have elapsed, whichever occurs first, unless otherwise agreed.

ARTICLE X: INCIDENT RESPONSE AND BREACH NOTIFICATION

10.1 Incident Response Plan

A formal plan establishes phases for Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. On‑call rotations ensure twenty four hours availability.

10.2 Detection and Alerting

Automated alerts trigger on unusual authentication patterns, excessive failed logins, anomalous data exports, or deviations from network baseline thresholds.

10.3 Customer Communication

In the event of a confirmed breach involving customer data, Impulsum will notify affected customers without undue delay and no later than seventy two hours after confirmation, providing known facts, impact scope, mitigation steps, and contact points. All notifications will comply with applicable breach-notification laws, including newly enacted state statutes such as the Maryland Online Data Privacy Act (MODPA), which require disclosure of the categories of affected information, potential harm, and specific mitigation measures taken.

10.4 Regulatory Coordination

If an incident implicates personal data of EU residents or subjects Impulsum to mandatory reporting under state breach laws, Legal Counsel will coordinate filings with supervisory authorities.

10.5 Law Enforcement Exceptions

In accordance with applicable state and federal laws, breach notification to affected customers may be delayed upon the written request of law enforcement if such disclosure would impede a criminal investigation or pose a national security risk. Impulsum will document and retain such delay requests where applicable. For consistency, breach notifications will also follow the processes and timelines described in our Privacy Policy, ensuring alignment across all customer-facing commitments.

ARTICLE XI: CLIENT‑SIDE SECURITY

11.1 Supported Browsers

We support the latest two stable versions of Chrome, Firefox, Safari, and Edge. Using unsupported browsers may reduce security controls such as Content Security Policy adherence.

11.2 Content Security Policy

The web application defines a strict policy that limits script sources to impulsum.me, Cloudflare CDN, and subdomains listed in Clause 3.2. Inline scripts are disallowed except where necessary and then protected with Hash‑Based Message Authentication Codes.

11.3 Secure Cookies

Session cookies are flagged as Secure, HttpOnly, and SameSite Strict. They expire after sixty minutes of inactivity.

11.4 Extension Security

When we introduce browser or desktop extensions, each build will be signed and checksums published. Extensions communicate only with impulsum.me endpoints and never embed third‑party trackers.

ARTICLE XII: PHYSICAL AND ENVIRONMENTAL SECURITY

12.1 Data Center Controls

AWS data centers adhere to industry recognized standards for physical security, including badge access, biometric scanners, closed‑circuit television monitoring, and onsite security staff.

12.2 Corporate Facilities

Impulsum operates as a remote first company. The minimal physical infrastructure—shared collaboration spaces and a registered office—hosts no customer data. Company issued laptops employ full disk encryption, automatic screen lock, and remote wipe.

ARTICLE XIII: CHANGE MANAGEMENT AND SECURE DEVELOPMENT

13.1 Change Control Board

All production facing changes require approval from a board comprising Engineering, Security, Operations, and Product Management. Emergency fixes follow an expedited path but undergo retrospective review within twenty four hours.

13.2 Versioning and Rollback

Each release is tagged in Git and mapped to container image digests. Rollback to a prior known good version is automated through CodeDeploy blue green deployments.

13.3 Infrastructure as Code

All cloud resources are provisioned with Terraform. Plan files are peer reviewed and scanned with a policy as code engine to detect risky configurations (such as open ports or public S3 buckets).

ARTICLE XIV: BUSINESS CONTINUITY AND DISASTER RECOVERY

14.1 Backup Strategy

Incremental backups run every fifteen minutes, with daily synthetic full backups. Backup data is retained for thirty days in a physically separate AWS region and is encrypted with a secondary key hierarchy.

14.2 Recovery Point and Recovery Time Objectives

The standard recovery point objective is fifteen minutes. The recovery time objective for critical services is four hours. Annual failover tests validate these targets.

14.3 Pandemic and Workforce Continuity

Critical functions can be executed remotely, and all essential personnel possess redundant internet access and power solutions.

ARTICLE XV: ACCOUNT TERMINATION AND DATA DELETION

15.1 Self Service Deletion

Customers may initiate account deletion under the Settings ▸ Advanced menu. Verification is completed through multi factor authentication.

15.2 Deletion Workflow

Within twenty four hours Impulsum schedules removal of active database rows, search indexes, and cached analytical results. Cold backups containing the customer’s data are purged within thirty days.

15.3 Model Training Implications

If the customer disabled Confidential Mode at any point, portions of their data may reside in prompt logs held temporarily by model providers. Those logs age out within the contractual thirty day window. Impulsum will not incorporate deleted customer data into any future fine‑tuning or training activities.

15.4 Customer Acceptance of Model Log Retention Risk

Where a customer disables Confidential Mode, they acknowledge and accept that certain ephemeral data (such as prompts and responses) may be stored temporarily (up to 30 days) by third-party model providers solely for operational integrity, subject to the zero-retention commitments detailed in Section 7.2. Customers operating in high-sensitivity environments are strongly encouraged to enable Confidential Mode at all times.

ARTICLE XVI: CERTIFICATIONS AND AUDIT REPORTS

16.1 SOC 2 Report

The latest SOC 2 Type II report covering Security, Availability, and Confidentiality Trust Services Criteria is available on request under a nondisclosure agreement.

16.2 ISO 27001 Certification Roadmap

We are undergoing ISO 27001:2022 certification with an anticipated completion date in the second quarter of twenty twenty six. Once certified, the certificate and statement of applicability will appear on our Trust Center.

16.3 Customer Audits

Enterprise customers may, once per twelve month period and upon sixty days written notice, perform a security audit or appoint an independent auditor subject to mutually agreed nondisclosure terms. All audits must avoid interfering with production operations and respect the confidentiality of other customers. Audits must not expose the confidential information of other clients or reveal security-sensitive configurations unrelated to the requesting customer’s environment.

16.4 Confidentiality and Non-Waiver of Liability

All certifications, audit summaries, and security documents shared with customers are confidential and may not be reproduced or disclosed without Impulsum’s prior written consent. Sharing such materials does not constitute a waiver of any disclaimers or limitations of liability set forth in the Terms and Conditions or any applicable agreement.

ARTICLE XVII: REPORTING, QUESTIONS, AND CONTACT INFORMATION

17.1 Security Inquiries

For security questions please email info@impulsum.me. Routine support requests should continue to use info@impulsum.me or the in app chat. All requests for security reports or compliance documentation are subject to confidentiality and non-disclosure requirements and must comply with Impulsum’s data protection and access control policies.

17.2 Urgent Notifications

If you discover a high severity vulnerability affecting Impulsum or observe suspicious activity believed to compromise customer data, contact the twenty four hours incident bridge at info@impulsum.me. Do not include sensitive exploit details over voice. Provide a callback number and encrypted proof of concept over PGP to our security inbox.

ARTICLE XVIII: DOCUMENT MAINTENANCE AND REVIEW

18.1 Revision Schedule

This Security Document is reviewed at least annually by the Security Steering Committee or sooner if material changes to services, infrastructure, or regulatory obligations occur. Reviews will also be conducted promptly following the enactment of significant new privacy or data security laws, including but not limited to the Tennessee Information Protection and Responsible AI Act (TIPRA), to ensure that controls reflect the latest statutory requirements such as data minimization and AI governance standards.

18.2 Version Control

The canonical version resides in the corporate knowledge base with semantic version tags. Change history, including description, author, reviewer, and approval date, is preserved for seven years.

18.3 Effective Date

This version becomes effective on August 8, 2025 and supersedes all prior versions.