Building Trust Through Transparency: Our Security Practices

An enterprise customer chose us over a competitor for one reason: we had a public security page. The competitor did not. Both platforms had roughly equivalent features. Both had similar pricing. But when the customer's security team asked "how do you protect our data?" we had a clear, public answer. The competitor said "we will get back to you" and sent a PDF three weeks later.

Transparency about security practices is a competitive advantage. It costs very little to produce and influences purchase decisions at every scale, from individual developers who want to know their API keys are safe to enterprise teams with formal security review processes.

The security page

Every developer platform should have a public security page. Not a marketing page with vague assurances. A specific, technical page that answers the questions a security engineer would ask during an evaluation.

Our security page covers six topics.

Encryption. We use AES-256 for data at rest and TLS 1.3 for data in transit. All API communication is encrypted. Database storage is encrypted. Backup storage is encrypted. We state these specifics because "we use encryption" means nothing without the details.

Authentication. API keys use scoped permissions with role-based access control. Session tokens use signed session tokens with rotation. We describe the authentication model, the token lifecycle, and the permission hierarchy.

Payment security. We handle payments through PCI-certified processors. We never store card numbers, CVVs, or raw payment credentials on our servers. Payment data flows directly from the developer's application to the payment processor. Our systems see transaction confirmations, not card details.

[Rate limiting](/blog/rate-limiting-ai-agent-experience) and abuse prevention. We describe our rate limiting tiers, adaptive abuse detection, and the specific limits for sensitive endpoints. Authentication endpoints: 10 attempts per 15 minutes. The transparency helps developers configure their own systems to stay within limits.

Data handling. What data we collect, how long we retain it, and how developers can export or delete their data. We address GDPR compliance for European developers and describe our data retention policies.

Infrastructure security. How our servers are configured, how access is controlled, and how we monitor for intrusions. We do not describe our specific infrastructure provider or internal architecture (that would be oversharing), but we describe the security posture.

Incident communication

When something goes wrong -- and eventually something does -- how you communicate determines whether developers trust you more or less afterward.

Our incident communication follows a timeline protocol.

Detection. We detect the incident through monitoring, alerting, or report. Internal response begins immediately.

Initial notification (within 2 hours). We notify affected developers that we are investigating an issue. We state what we know, what we do not know yet, and when we will update. We do not speculate. We do not minimize. We do not wait until we have all the answers.

Updates (every 4 hours during active incidents). Regular updates even if the status has not changed. "We are still investigating" is better than silence. Silence during an incident breeds anxiety and speculation.

Resolution notification. When the incident is resolved, we notify all affected developers with a summary: what happened, what the impact was, and what we did to fix it.

Post-mortem (within 1 week). A detailed post-mortem published publicly. Root cause analysis. Timeline of events. What we are doing to prevent recurrence. No blame. No vague promises. Specific actions with timelines.

Developers do not expect perfection. They expect honesty. A well-communicated incident builds more trust than a flawless record that you suspect is just luck.

SOC 2 preparation

SOC 2 compliance is a common requirement for enterprise evaluations. We are on the path toward Type II certification, and we communicate our progress openly.

Our public roadmap includes the SOC 2 timeline: which controls we have implemented, which are in progress, and our expected certification date. Developers evaluating us for enterprise use can see exactly where we are instead of getting a vague "we are working on it."

The SOC 2 journey is genuinely useful beyond the certification itself. The control framework forces discipline around access management, change control, incident response, and monitoring. These practices improve our security posture whether or not a customer ever asks for the certificate.

We share the specific controls we have implemented (access reviews, change management, monitoring) on our security page. Enterprise customers who need SOC 2 can see the substance behind the upcoming certification.

Penetration testing

We engage third-party security firms for penetration testing on a regular basis. The testing covers our API endpoints, authentication flows, payment processing, and internal systems.

We publish summary reports from these tests on our security page. Not the full detailed report (which could be a roadmap for attackers) but a summary that includes: scope of testing, methodology, number of findings by severity, and confirmation that all critical and high-severity findings have been remediated.

This transparency serves two audiences. Developers get assurance that our security is externally validated. Our team gets accountability to fix findings promptly, because the summary publication date creates a deadline.

Responsible disclosure

We run a responsible disclosure program that invites security researchers to report vulnerabilities.

The program has defined response SLAs. We acknowledge reports within 24 hours. We triage (assess severity and impact) within 72 hours. We provide a fix timeline within one week for confirmed vulnerabilities. We deploy fixes for critical issues within 48 hours of confirmation.

Researchers who submit valid findings receive public acknowledgment (if they want it) and are listed on our security page. We do not currently offer monetary bounties, but we provide API credits and early access to new features as recognition.

The disclosure process is straightforward. Researchers email our security address with a description of the vulnerability, reproduction steps, and their assessment of severity. We respond within 24 hours, regardless of severity.

We have found that running a public disclosure program attracts more responsible reporting and fewer irresponsible disclosures. Researchers who know there is a process are more likely to follow it.

Building trust incrementally

Security trust is not binary. It builds over time through consistent demonstration.

For a platform starting from zero, here is a five-step progression.

Step 1: Publish a security page. Even a simple page listing your encryption standards, authentication model, and data handling practices is better than nothing. It can be a single page with six sections. Write it in an afternoon.

Step 2: Implement and publish an incident communication protocol. Developers need to know that when something goes wrong, they will hear about it promptly and honestly. Define the protocol before you need it.

Step 3: Launch a responsible disclosure program. Create the security email address, define response SLAs, and publish the policy. Security researchers will find your vulnerabilities whether you have a program or not. A program ensures they report them instead of exploiting them.

Step 4: Engage external penetration testers. Third-party validation is more credible than self-assessment. Publish the summary results.

Step 5: Pursue formal compliance certification. SOC 2, ISO 27001, or whatever your market requires. This is the most expensive step but it unlocks enterprise customers who require formal certification.

Each step builds on the previous one. You do not need to complete all five before launching. Step 1 alone puts you ahead of most API platforms.

Security transparency is not about proving you are perfect. It is about showing developers that you take security seriously, that you know what you are doing, and that when things go wrong, you will handle it responsibly. That is what trust is built on. Not promises. Practices.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.