Security and responsible disclosure

Architecture as a security control

Every Primanza product has its own repository, its own deployment, its own database, its own credentials, its own authentication and its own security boundary. There is no common account system, no common database and no common application secret across the portfolio.

This is a deliberate containment design, and it is worth stating what it rests on. A product runs at an address of its own — a domain of its own, or a subdomain of primanza.com — and either is a routing and naming arrangement: it does not put products on shared infrastructure, and it does not give one product a credential, a session or a database connection belonging to another. Cookies are scoped to each product's own host and never to primanza.com as a parent domain, so a session cannot travel sideways; the Cookie Policy sets that out in detail.

What that buys is containment rather than immunity: a compromise of one product does not carry a path into another product or into this site. It is a bounded claim, not an absolute one. The layer genuinely shared across the portfolio is the domain registrations and DNS the company maintains, and a compromise there would be a compromise of the naming layer — which is why that configuration is in scope for disclosure below.

The corporate site is statically rendered, has no database, no authenticated surface and no user accounts. It is served over HTTPS with HTTP Strict Transport Security, a restrictive Content Security Policy and standard hardening headers. The most reliable way to secure data is to not hold it, and this site holds almost none.

Certification and independent testing

Position as at 4 October 2026: Primanza holds no security certification — no SOC 2 report and no ISO 27001 certificate — and no independent penetration test has been completed, either of ReplyTune or of this site. None is claimed anywhere on this site or in any document it publishes.

An earlier version of this page committed to arranging independent testing before the first product carried customer data. ReplyTune is in production and that test has not yet taken place. When a test is completed, this page will publish its date, its scope and who carried it out.

Until then, the controls ReplyTune operates are the ones listed in section 7 of its Data Processing Addendum: encryption in transit and storage with providers that encrypt at rest, one-way password hashing, isolation of each customer's data, role-based access for its team, two-factor authentication and an append-only audit log for administrators, rate limiting on sign-in, and encrypted backups that expire within 30 days. ReplyTune's product page on primanza.com summarises its data and security position, with a source for each answer.

One deliberate weakness in this site's own configuration is disclosed here rather than left to be discovered. The Content Security Policy permits inline scripts (`script-src 'unsafe-inline'`). Every route is statically prerendered, and both the framework's bootstrap payload and the structured-data block are emitted inline at build time; a nonce-based policy has to be generated per request and would force every page out of static rendering. The site accepts no user input that is reflected back into a page as HTML — the contact form's only destination is a mailbox, and its own states are fixed strings — so there is no reflected-injection sink for that directive to protect. The remaining directives are strict and do real work: no plugins, no base-tag rewriting, no off-origin form submission, no framing. If a third-party script or any surface that echoes user input into the DOM is added, this trade is revisited before it ships.

Reporting a vulnerability

Email security@primanza.com. A machine-readable pointer to this policy is published at /.well-known/security.txt in accordance with RFC 9116.

A report that lets us reproduce the issue gets fixed faster. Please include:

• The affected domain, URL or endpoint.
• A description of the issue and why you believe it is a security problem.
• Clear steps to reproduce, and a proof of concept if you have one.
• The impact you assess, and any prerequisites an attacker would need.
• How you would like to be credited, if you would.

Report in English. If you want to encrypt a report, say so and we will arrange a key — we do not publish one we would not reliably monitor. Do not include other people's personal data in a report: describe the exposure, do not send us the exposed records.

Scope

In scope:

• primanza.com and the subdomains under it operated by the company.
• The Primanza products, at the addresses on which they run, as listed in the product index on primanza.com.
• The company's published email and DNS configuration, for primanza.com and for each product domain, including subdomain delegation and any dangling record that could be claimed by someone else.

Out of scope: any system not operated by Primanza, including our hosting, DNS, email and infrastructure providers — report those to the provider under its own policy. Also out of scope, unless you can demonstrate a concrete and realistic impact: missing security headers with no exploitable consequence, missing SPF, DKIM or DMARC records already accounted for, output of automated scanners without a working proof of concept, rate limiting on unauthenticated public pages, denial of service, social engineering or phishing of our people, physical attacks, issues requiring a rooted or compromised device or a fully man-in-the-middle position, self-XSS, clickjacking on pages with no sensitive action, and vulnerabilities in third-party software for which no patch exists.

This corporate site has no accounts, no session, no payment and no personal data store. Report classes that presuppose one do not apply here — but they do apply on the products, which are real applications.

Rules of engagement

Research within this policy is authorised. Research outside it is not, and the safe harbour below does not cover it. While testing, you must:

• Act in good faith, with the purpose of finding and reporting a vulnerability — not of exploiting one.
• Use only your own accounts and your own test data. Do not access, modify, delete or exfiltrate data that is not yours.
• Stop at proof. Once you have established that a vulnerability exists, stop — do not pivot, escalate or explore further.
• Cause no harm to service availability or integrity: no denial-of-service or volumetric testing, no destructive testing, no automated scanning at a rate that degrades the service for anyone else.
• Leave nothing behind. Delete any data you obtained as soon as you have reported it, and remove any artefact your testing created.
• Do not use social engineering, phishing or physical intrusion against our people or premises. Attacking the person is out of scope; attacking the system is the point.
• Give us reasonable time to fix the issue before disclosing it publicly — see the timelines below.
• Comply with applicable law. This authorisation is ours to give for our systems; it is not, and cannot be, permission to break the law.

Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will consider your research to be authorised, and:

• We will not initiate or recommend legal action against you in connection with it, including under the Computer Fraud and Abuse Act, the Wyoming computer crimes statutes, or any other computer misuse law.
• We will not bring a claim against you under the anti-circumvention provisions of the Digital Millennium Copyright Act, and we waive any restriction in our Terms of Service or Acceptable Use Policy that would otherwise prohibit your research, to the extent needed to conduct it within this policy.
• If a third party brings legal action against you for research conducted in compliance with this policy, we will take reasonable steps to make it known that your conduct was authorised by us.
• We will treat an accidental, good-faith violation of this policy as a mistake to be discussed, not as a reason to withdraw this protection — provided you tell us promptly and stop.

The limits: this safe harbour is given by Primanza and binds Primanza. We cannot waive the rights of a third party, and we cannot bind a prosecutor or a court. It does not extend to systems we do not operate, and it does not apply if you act in bad faith or outside this policy.

If you are unsure whether something is authorised, ask security@primanza.com before you test it. We would rather answer the question in advance than argue about it afterwards.

What we commit to

In return for a report made under this policy:

• We acknowledge receipt within three business days.
• We give you an initial assessment — whether we can reproduce it, and how we rate the severity — within ten business days.
• We keep you informed at reasonable intervals while we work on a fix, and we tell you when it ships.
• We credit you by name or handle when the issue is resolved, if you want credit, and we omit you entirely if you do not.
• We aim to resolve issues within 90 days of the initial report, and we support coordinated disclosure at that point or earlier by agreement. If a fix genuinely needs longer, we will tell you why rather than let the clock run out in silence.
• We do not require you to sign a non-disclosure agreement as a condition of reporting, and we will not use one to keep a fixed issue quiet indefinitely.

Bug bounty

Primanza does not operate a paid bug bounty programme.

What it offers is a response from the person who can fix the problem, public credit if you want it, and the safe harbour above. If a paid programme is introduced, it will be announced on this page with its terms.

Product security

Each Primanza product handles its own security within its own boundary — its own credentials, its own dependency updates, its own incident response — and publishes its own security contact where it differs from the address above.

In an incident affecting a product, the people affected by that product are notified through that product, and any legally required notification to a regulator or data subject is made by the entity responsible, within the deadline the applicable law sets. This site is not the notification channel for a product incident, and an incident on this site would not affect a product. If you cannot find a product's security contact, security@primanza.com reaches us and we will route it.