Security and Data Handling

The Execution Index is a Ruby on Rails application operated by Unleash Epic, LLC, an Oregon limited liability company. It is a small, focused system with a small, focused surface area, and this page describes it as it is built today. Where a practice is still maturing, we say so at the bottom instead of leaving it out.

If your review needs something this page does not cover, write to john@unleashepic.com and you will get a direct answer from the person who wrote the code.

1. Architecture and hosting

• Hosting. The application runs on Render in the United States, in Render's Oregon region. The PostgreSQL database is a managed Render database in the same region. There is no other production environment and no other copy of the database.
• Transport security. TLS is enforced on every request. The application sets Rails' force_ssl in production, which redirects any plaintext request to HTTPS, sends HTTP Strict Transport Security on responses, and marks cookies secure.
• Passwords. Passwords are stored as bcrypt hashes with a work factor of 12. We never store, log, or transmit a plaintext password, and we cannot recover one. Password reset works by emailing a single-use token.
• Sessions. Sessions are held in cookies that are encrypted and signed with AES-GCM using the application's secret key, and marked HTTP-only and secure. No session data is readable or modifiable by the browser.
• Log hygiene. Production logs run at info level. Parameter filtering redacts passwords, email addresses, secrets, tokens, keys, salts, certificates, one-time passwords, social security numbers, and card security codes before anything is written to a log line.
• Provider certifications. Render publishes SOC 2 Type 2 and ISO 27001 certifications for its own platform. Those are our hosting provider's certifications covering their infrastructure. They are not certifications of Unleash Epic. See section 9.

2. Payments

• Stripe-hosted checkout. All payment is taken on Stripe's own hosted checkout pages. We create a checkout session over TLS to Stripe's API and redirect the buyer to the URL Stripe returns. Card numbers, expiry dates, and security codes are entered on Stripe's pages.
• No card data on our servers. We hold a Stripe customer reference and a checkout session reference. There is no column anywhere in our database for a card number, expiry date, or security code, so there is no cardholder data for us to lose.
• Webhook signature verification. Every inbound Stripe webhook is verified against the endpoint's signing secret using HMAC-SHA256 with a constant-time comparison. A request with a missing secret or an invalid signature is rejected with a 400 before any application logic runs. Unlock processing is idempotent, keyed on the Stripe session reference and enforced by a unique database index, so a duplicate delivery cannot grant access twice.

3. Data minimization by design

This is the section that matters most, because it is where the product's design does the security work rather than a policy asking people to behave.

Individual assessment answers exist for one purpose: producing the individual's own report. Nothing in the platform renders one person's item-level answers to their leader, their teammates, or a consultant. Team-level readings are built by a separate aggregation layer, and that layer is where the guarantees live.

Automated regression tests enforce all four. Our test suite walks every value in the team data package and fails the build if a member's first or last name, a leader's identity, or a raw individual score appears anywhere inside it. A separate test file exists solely to guard the small-roster blending, asserting that every per-task specific a small team could pin to a person is absent from the generated report. Further tests confirm that team phase readings are bands with no scores, that systems layers stay unreported below the threshold, and that the confidentiality promise itself is still printed in the individual report. These tests run on every change, so a future edit that would leak an individual through a team surface breaks the build instead of shipping.

Individual materials are the deliberate exception. A person's own report carries their own name and is delivered to them, and the coaching materials for an assigned member are built to brief the professional working with that person.

4. Document generation

• Rendered inside our own infrastructure. PDFs are produced by a headless Chromium engine installed in our own application container. There is no third-party PDF service, no document conversion API, and no external rendering step.
• Document content does not leave our servers. The generated HTML is handed to the browser engine in-process as an inline data URL. It is never uploaded, never posted to an endpoint, and never written to a shared location.
• No AI model generates client content. Every report, playbook, plan, prompt, and deck is produced by authored Ruby: fixed scoring weights, authored content matrices, and deterministic templates. No third-party language model is called at runtime to write any part of a client document.
• Deterministic output. The same inputs always produce the same document. A report can be audited line by line against the data that produced it, and regenerating it a year later gives the same result.

5. Third parties

We use a short list of service providers, and we publish it. The Privacy Policy contains a subprocessor table naming every one of them, what it is for, exactly what data it receives, and where it runs. If your review requires a data processing agreement or a completed security questionnaire, write to us.

6. Email

Transactional email is delivered through Resend over an authenticated TLS connection. Results email contains the recipient's first name, their score, their archetype, and a link to their report. It is sent only to the address on the account that took the assessment. Results are linked rather than attached, so an intercepted mailbox forward does not carry the document itself.

7. No analytics or advertising trackers

The platform runs no analytics package, no advertising pixel, no session recording, no heat mapping, and no cross-site tracker. There is no Google Analytics, no Meta pixel, no Segment, and no equivalent. This is verifiable by viewing source on any page.

Two third-party requests do occur on page load and we would rather name them than let a reviewer find them: brand font files are served from Google Fonts, and videos on marketing pages are served from our marketing platform's content network. Both see standard web request data including the visitor's IP address. Neither receives account data. Campaign attribution is first-party: utm parameters are held in our own session cookie and stored on our own database.

8. Deletion

Account deletion is available from the account page. Deleting an account cascades to that user's assessments, their item-level responses, their dimension and phase scores, their workflow inventory including free-text notes, their team memberships, their nurture enrollments, and their deliverables.

Cached PDF documents live on the application container's own disk and expire within ninety days, swept by a scheduled job. A deletion request that needs those caches cleared sooner is handled manually on request.

Records already delivered to our email provider, our marketing CRM, our follow-up service, and Stripe's payment records are governed by those services' retention and are removed on request rather than automatically. We will tell you honestly which of those we have completed.

9. Practices under active development

We would rather be trusted than impressive, so here is the honest position. Unleash Epic does not hold a SOC 2 report, an ISO 27001 certificate, or any other third-party security certification. Our hosting provider holds theirs, and that covers their infrastructure rather than our application. Security hardening on the platform is ongoing work with an active roadmap, and we prioritise it alongside product work rather than after it.

If your organization requires a certification we do not yet hold, tell us during your review and we will tell you plainly whether and when we expect to have it. We will not claim one we do not have.

10. Responsible disclosure

If you believe you have found a vulnerability, please tell us before you tell anyone else. Send it to john@unleashepic.com with enough detail to reproduce it.

• We will acknowledge your report within 5 business days.
• We will tell you what we found and what we are doing about it.
• We will credit you if you want to be credited, and stay quiet about you if you do not.
• We will not pursue legal action against a researcher who reports in good faith, works with data they are authorized to access, avoids degrading the service, and gives us reasonable time to fix the issue before publishing.

Please do not run automated scanners against production, do not attempt to access another user's data, and do not test denial of service. If you need a test account to look at something properly, ask and we will set one up.

11. Contact

Unleash Epic, LLC
Security and privacy: john@unleashepic.com
Web: unleashepic.com