Serious software needs serious operating standards.
The Astackra Trust Center explains how we think about security, privacy, AI responsibility, access control, observability, recovery, accessibility and production readiness. It is designed to help serious buyers evaluate us before procurement or technical discovery.
Trust is an architecture problem, not a badge.
Identity & access
Role-aware permissions, least-privilege access, explicit ownership and revocable access paths.
Protected secrets
API keys and credentials stay on secure server/environment layers—not in browser code or public repositories.
Human authority
High-impact or ambiguous AI-assisted decisions remain behind explicit human review where appropriate.
Observable systems
Important state transitions, errors, AI-assisted actions and escalations should be inspectable.
Recovery by design
Retries, fallbacks, backups, rollback paths and exception ownership are part of production planning.
Truthful claims
Live builds, prototypes and concept demonstrations are labeled honestly; we do not invent certifications, outcomes or offices.
What may AI observe, recommend, act on or escalate?
Observe
Read approved documents, messages, records and workflow state required for a bounded task.
Recommend
Summarize, classify, draft, prioritize, surface evidence and suggest next actions.
Act
Execute low-risk, reversible and permissioned actions through approved tools.
Escalate
Hand uncertainty, policy-sensitive work, financial exposure and professional judgment back to a person.
Questions we want answered before calling a system production-ready.
Authentication & authorization
- Who can sign in and how?
- Which data belongs to which role?
- Which actions require elevated permission?
- Can access be revoked cleanly?
Data classification & privacy
- What information is collected and why?
- Where is data stored and transmitted?
- Which third parties process it?
- What retention and deletion behavior is required?
Secrets & infrastructure
- Are keys stored outside public code?
- Are production and development environments separated?
- Who can change environment variables or deployment settings?
- Are sensitive logs avoided or protected?
AI quality & failure
- What evidence grounds AI output?
- What happens when confidence is low?
- How are malformed or unsafe outputs rejected?
- What is the deterministic fallback?
Backup, rollback & recovery
- Are backups current and testable?
- Can critical changes be rolled back?
- Can important actions be retried safely?
- Who owns recovery after launch?
Monitoring & observability
- Can failures be detected?
- Are important state changes visible?
- Can model usage and cost be monitored?
- Can incidents be traced to a specific request or workflow?
Know what data goes where.
The parts that separate a demo from an operating system.
Permissions
Users only see and change what their role requires.
Validation
Inputs, outputs and state transitions are checked before consequential actions.
Fallbacks
AI failure does not have to become workflow failure.
Audit trail
Important actions and ownership changes remain explainable.
Cost controls
Model calls, storage and high-cost paths should be measurable and bounded.
Performance
Fast page delivery, efficient APIs, caching and responsive interaction matter after launch.
Accessibility
Keyboard access, focus states, contrast, readable error messages and responsive layouts are production concerns.
Operational ownership
Someone must own quality, incidents, data and change after launch.
Useful standards—not borrowed credibility.
No fake certifications
We will not imply ISO, SOC 2, HIPAA, PCI or any other formal certification unless it has actually been completed.
No fake locations
Global market pages describe remote delivery and market relevance without pretending we operate physical offices we do not have.
No invented results
Where quantified outcomes are unavailable, we describe the system, engineering contribution and workflow rather than fabricating ROI.
What a serious client can ask us before engagement.
Architecture review
Hosting, environments, integrations, data flow, model providers, authentication and system boundaries.
Delivery controls
Milestones, ownership, QA, staging, review gates, rollback and deployment procedures.
AI controls
Grounding, validation, permissions, escalation, human review and failure handling.
Privacy discussion
What data is collected, what is sent to third parties, and what retention model is required.
Operational support
Monitoring, incident ownership, maintenance, documentation and post-launch change.
Accessibility & performance
Responsive behavior, keyboard navigation, contrast, loading behavior and Core Web Vitals thinking.
Have security, privacy or architecture questions before you start?
Bring them into discovery. We would rather answer difficult technical questions early than bury them after a proposal.
Compliance pack
The documents procurement asks for, ready now rather than on request. Both are generated from the same data as the tables on this page, so they cannot drift out of step with it.
Sub-processors
Everything astackra.com relies on that could see data, what each one does and where it processes it. If a sub-processor is added or replaced, clients under an active engagement get at least 30 days notice and may object on reasonable data protection grounds.
| Sub-processor | What it does | What it sees | Where |
|---|---|---|---|
| Website hosting and outbound email | Serving astackra.com and delivering email sent by the site | Anything submitted through a form: name, email, phone, message | Named in the data processing agreement, and on request |
| OpenAI | The NOVA assistant on this site — generating answers to questions asked of it | The text of the question asked and the page it was asked from | United States |
| ipapi.co | Resolving a city and network name from a visitor IP address, so we know which markets our visitors are in | The IP address, sent once per visitor per day. It is not stored by us: what we keep is a one-way hash, the city, and the network name | United States |
| Google Fonts | Delivering the typefaces used on some pages | The visitor IP address, as with any request to a third-party server | Global content delivery network |
| Cloudflare (cdnjs) | Delivering one JavaScript library used by the document sandbox, and only on that page | The visitor IP address | Global content delivery network |
Current as at 1 October 2026. This list covers astackra.com itself. Sub-processors used on a client engagement are listed in that engagement's agreement, and clients get at least 30 days notice before one changes.
How long things are kept
Deletion is a design decision, not an afterthought. Website measurement records delete themselves after 120 days because the code does it on a schedule, not because a policy says so.
| What | How long | Why |
|---|---|---|
| Enquiries and project briefs | 24 months from the last contact | So we can pick up a conversation that went quiet, and so we can answer questions about what was discussed |
| Booked consultations | 12 months | Scheduling and follow-up |
| Website measurement records | 120 days, then deleted automatically | Cookie-free counts of page views and events. No cross-site tracking and no advertising identifiers |
| Visit records | 90 days, then deleted automatically | City, country, network name, pages viewed and referrer for one visit, so we can see which markets reach us and follow up when a business shows real interest. The IP address is used once to resolve the city and is never stored; a one-way hash recognises a return visit. Visitors sending Do Not Track or Global Privacy Control are counted but not located |
| Consent records | 24 months | Evidence of what a visitor agreed to and when |
| Assistant conversations | Not retained beyond the session unless an enquiry is created from it | Support and quality |
| Client project data | For the term of the engagement, then returned or deleted within 30 days of a written request | Delivery. Set out in the engagement agreement |
| Financial records | As required by law | Statutory obligation |
You can ask for anything we hold about you to be sent to you or deleted, at any time, by writing to hello@astackra.com. We act on it within 30 days and usually the same week.
Incident response
What happens if something goes wrong, written down before it does:
- Detect. Automated health checks run on a schedule and alert a person on failure. Anyone — client, visitor or researcher — can report a problem to hello@astackra.com, and a security report is acknowledged within one working day.
- Contain. The first action is to stop the bleeding: revoke credentials, disable the affected route, isolate the system. Investigation comes second, because the priority is limiting harm rather than understanding it.
- Assess. What was affected, whose data, over what period, and whether it left our control. Where the answer is unclear, we say it is unclear rather than guessing downwards.
- Notify. Affected clients are told without undue delay and within 48 hours of us becoming aware, with what we know at that point and updates as the picture develops. Where a supervisory authority must be notified, the client as controller leads that and we provide what they need.
- Fix and record. A fix, then a written account of what happened, why, and what changed so it cannot happen the same way again. Clients under an active engagement get that account whether or not they ask for it.
We do not take legal action against anyone who reports a vulnerability in good faith and gives us reasonable time to fix it.
Where AI sits in all of this
Client data is not sent to any third-party AI service without written agreement about which service, for what purpose and on what terms — and where one is used, it is one contractually bound not to retain the data or train on it. Where the workflow allows, data is redacted before it goes anywhere it does not need to be. This is written into the data processing terms above rather than left as a reassurance on a web page.
The assistant on this site is a separate matter and is covered in the sub-processor table: questions asked of it are processed by OpenAI in the United States. If that is a problem for your organisation, do not put confidential information into it — and tell us, because it is the sort of constraint that shapes how we would build for you.
If you would rather use your own paper
Send it over. We sign client NDAs and client data processing agreements as readily as our own, and we will tell you plainly if a clause is one we cannot meet rather than signing and hoping.
Live system status
Reduced capability.
Checked automatically every fifteen minutes from outside the application. Last check 7 minutes ago · 100% healthy across the recorded window.
- WebsiteEvery page is being served normally.Operational
- Project form and contactEnquiries can be submitted.Operational
- Enquiry deliveryEnquiries are stored and delivered to the team inbox.Operational
- NOVA assistantThe language model is unavailable, so NOVA is answering from our knowledge base and routing to a human.Reduced capability
- Search and AI feedsSitemap and llms.txt are being served to search engines and AI crawlers.Operational
These states are written by our own monitoring, not by hand. If something here says reduced or unavailable, it is because it genuinely is — and an engineer has already been paged by email.
Related