Security & payment scope

1. Where card data goes

We do not store, process or transmit cardholder data on our own servers. Subscription payments go to Stripe through a Stripe-hosted form; the card number is entered on Stripe's page and reaches Stripe directly.

That places us in the scope of SAQ A. That is the questionnaire for a merchant who has fully outsourced card handling. PCI DSS v4.0.1 removed requirements 6.4.3 and 11.6.1 from SAQ A, but only for merchants who can show their payment pages are not susceptible to script tampering — so we maintain a script inventory for any page in the payment flow regardless.

We are not certified as a PCI service provider, and we do not claim to be. What we can tell you is precisely which systems are in the payment path, which is what your own assessment needs from us.

Point of sale is a different scope

A point-of-sale install is a different scope. Card data there is handled by the payment terminal and the processor, never by the application we write — but the merchant, not us, is the one with the PCI obligation, and the applicable questionnaire depends on their terminal and connection.

If you are a merchant running one of our POS installs and you need help working out which questionnaire applies to you, ask. It depends on your terminal, how it connects and whether it is validated as point-to-point encrypted — and getting that wrong is expensive in a way that a short conversation is not.

2. Credentials and secrets

• Platform credentials — API keys, tokens, signing secrets — are encrypted at rest with Fernet and are never returned in full by any endpoint. Reading a setting back gives you a masked preview and where it came from, not the value.
• Each client system holds its own signing secret. One client’s credential cannot sign a request on behalf of another, and a compromised site cannot reach a different client’s data.
• Passwords are stored as bcrypt hashes. We cannot tell you your password because we do not have it.
• Client credentials we hold to operate a service — an ad account, a business profile — are held in the automation platform’s own credential store, not in our application database, and are revocable by you at any time from your side.

3. Who can reach what

This is a small company and we are not going to pretend it has a 24-hour security operations center. What it has instead is a very small number of people with access, single-purpose credentials, and multi-factor authentication on every account that offers it.

Administrative access to a client’s systems exists for as long as we are operating them and is removed at handover. If you would like it removed sooner, or scoped more narrowly, that is a reasonable request and we will do it.

4. In transit and at rest

• Everything is served over TLS. Certificates renew automatically and plain HTTP redirects rather than serving.
• Requests between a client’s site and our platform are signed per-tenant and timestamped, so a captured request cannot be replayed.
• Databases are managed services with encryption at rest and point-in-time recovery. Backups roll on a 35-day cycle — see the retention schedule.

5. AI systems

Content sent to a model provider is not used to train a public model, and spend is capped per client so a runaway process cannot produce an unbounded bill. The AI use policy covers what the models are permitted to do with what they see.

6. If something goes wrong

Where a breach affects personal data we hold on your behalf, we will tell you without undue delay and in any case within 72 hours of becoming aware, with what we know at the time rather than waiting until we know everything. California law requires notice to affected residents in the most expedient time possible; where you are the controller, that notice is yours to give and we will give you what you need to give it.

7. Reporting a vulnerability

Email admin@inericasystems.com with “security” in the subject. We will acknowledge within two business days.

If you report a vulnerability in good faith, give us reasonable time to fix it, and do not access or alter data that is not yours, we will not pursue legal action against you and we will credit you if you want the credit. We have no bug bounty budget and will not pretend otherwise — but we would much rather hear it from you than from a customer.

8. What we do not have

Said plainly, because a security page that lists only strengths is not a security page. We hold no SOC 2 report, no ISO 27001 certificate and no PCI service-provider attestation. We do not run a formal penetration testing program. If your procurement process requires any of those, we will not be able to satisfy it today, and it is better that you know that now than three weeks into a review.