Source control and review
All work is version-controlled from the first commit. Changes are reviewed before they reach production, and history is retained so any change can be traced to when and why it was made.
Security and engineering practices
How we build, where credentials live, what happens when something goes wrong, and what we do not yet have. Written to be checked rather than skimmed — much of it is verifiable against this site. The practices below apply to every engagement, whatever service it starts as, and sit inside the process we follow.
Practices
How the work is done.
Secrets management
Credentials, API keys and tokens are held in the platform’s encrypted secret store — never in source, never in a repository, never in a chat message. Secrets are scoped to the narrowest permission that works.
Dependency management
Third-party packages are kept current and audited for known vulnerabilities. We prefer fewer, well-maintained dependencies over convenience libraries that expand the attack surface.
Transport and storage
Everything is served over HTTPS with HSTS. Data in transit is encrypted; data at rest uses the platform’s encryption. We do not copy client data onto local machines unless a task genuinely requires it.
Access control
Access is granted per person and per system, on least privilege, and removed when an engagement ends. Multi-factor authentication is required on every account that supports it.
Input handling
User input is validated and escaped at the boundary. Output is escaped on the way out. Abuse prevention — rate limiting, bot verification, content checks — runs server-side, never only in the browser.
Incident response
If something goes wrong.
No process prevents every incident. What matters is whether the people affected hear about it quickly and accurately.
01
Detect
Monitoring and alerting on the systems we run, plus a documented route for a client or a member of the public to report something.
02
Contain
Limit the blast radius first — revoke credentials, isolate the affected system — before investigating at leisure.
03
Notify
Tell the affected client without delay, with what is known and what is not. We would rather report early and incomplete than late and tidy.
04
Remediate
Fix the cause, not only the symptom, and verify the fix.
05
Review
Write up what happened and what changes as a result. Shared with the client.
Your data
Ownership and processing.
What you own
- Source code and repositories, in your accounts
- Cloud infrastructure and hosting accounts
- Domains, DNS and certificates
- Databases and the data in them
- Documentation produced during the engagement
How we handle it
- Access is scoped to the engagement and revoked at the end
- We will sign a Data Processing Agreement as your processor
- A mutual NDA is available before you share anything sensitive
- Sub-processors are disclosed before they are used
- Production data is not copied into development without agreement
Being straight about it
What we do not have.
Incitari Technologies LLC was formed in 2026. Claiming certifications we do not hold would be the fastest way to fail the review this page exists to pass, so:
SOC 2Not held. The controls above are the groundwork; certification follows demand, not the other way round.
ISO 27001Not held.
Penetration testNo third-party report yet. We will commission one where an engagement warrants it.
InsuranceAsk us for the current position in writing before contracting. We confirm it directly rather than publishing limits on a page that can go stale.
If your procurement process needs something not listed here, ask. A clear “not yet, and here is what we do instead” is more useful to both of us than a vague yes.
Reporting
Found a vulnerability?
Email info@incitari.com with the details and how to reproduce it. We will acknowledge within two business days, keep you updated, and will not pursue anyone who reports in good faith and does not access or alter data that is not theirs.