The Cross-Section Nobody Covers
There is a gap in the market that most founders discover the hard way.
On one side, you have indie dev shops and freelancers. They ship in weeks, charge fixed prices, and move fast. But hand them a vendor security questionnaire or ask them to survive an enterprise InfoSec review and the whole thing falls over. They never had IAM discipline, their secrets live in .env files checked into the repo, and their audit trail is "check the git log."
On the other side, you have the Big Four and the large SIs. They can survive any audit. They also take six months to deliver what a lean team could ship in six weeks, and they charge accordingly.
Nobler sits in the overlap. We ship on indie-shop timelines and we ship code that clears the kind of security posture we used to build for federal customers. That combination is the whole business.
Where the Rigor Comes From
Before starting Nobler, I spent years as an AWS Federal Solutions Architect. That means real audits, real control frameworks, real access-control reviews, and real data handling policies. When you are designing for SLED and federal workloads, "we will add logging later" is not a sentence you are allowed to say.
Most of that rigor is not expensive to apply. It is expensive to retrofit. The trick is baking it in on day one, when your codebase is small and your infrastructure is twenty lines of Terraform, instead of trying to bolt it on at month eight when you have forty microservices and no idea who has access to what.
Here is exactly what we do.
1. Least-Privilege IAM From Commit Number One
The single most common failure we see in engagements we inherit: AdministratorAccess attached to half the roles in the account. Developers running local scripts with a personal IAM user that has full S3 and RDS permissions. A CI role that can delete any resource in the account.
From the start of every Nobler project, every role has a scoped policy. CI has the minimum it needs to deploy its specific stack. The application role can read the specific Secrets Manager secret it uses and write to the specific S3 bucket it owns. Nothing more.
This is not slower to set up. It is the same amount of Terraform either way. The difference is that you still have it working six months later when a security reviewer asks "who can read customer data?" and you have an actual answer.
2. Infrastructure as Code, No Console Changes
Every resource is defined in Terraform. We do not click in the AWS console to add a quick S3 bucket. If it is not in code, it does not exist. For more on why this mindset is worth the upfront cost, we covered our standard stack in Small Team, Big Architecture.
Why security reviewers care: they want to know that your infrastructure is auditable and reproducible. "Let me go check" is not an answer. "Here is the module that defines that" is.
Practical benefit: when a reviewer asks to see your network diagram, your encryption config, or your backup retention policy, you point at a file.
3. Secrets Never Live in Repos
Every credential, every API key, every database password lives in AWS Secrets Manager or Parameter Store. Applications read them at runtime via IAM. Developers never see them locally except through short-lived assumed roles.
No .env files in the repo. No shared password vaults with production credentials sitting in them for two years. No keys in Slack DMs.
This one practice, alone, eliminates the most common finding in every vendor security questionnaire: "How are production credentials managed?"
4. Audit Logging as a Baseline, Not an Afterthought
Three layers of logging on every project:
- CloudTrail capturing all AWS API calls, with multi-region delivery to a centralized logging account
- VPC Flow Logs for network-level traffic analysis
- Application-level audit events for every write operation against customer data (who did what, when, from where)
All three are enabled on day one. Not after the first security incident. Not when a customer asks. On day one.
The cost is trivial. The ability to answer "show me every action taken on this customer record in the last 90 days" is the difference between passing and failing an enterprise review.
5. Data Classification and Handling From Kickoff
In the first week of every build, we classify the data the product will handle. Public, internal, confidential, restricted. Each tier has prescribed handling: encryption at rest, encryption in transit, retention policies, access logging.
PII goes in its own schema with column-level encryption for anything sensitive. Payment data flows through Stripe and never touches our database. Health data triggers a different stack entirely with the appropriate compliance posture.
The sooner you classify, the sooner you make the right architectural choices. Retrofitting encryption and access controls on a schema that already has a million rows is a project. Building it in on an empty schema is a Terraform block.
6. Dependency Posture and SBOM
Every project runs Renovate for automated dependency updates. Every dependency is tracked in a Software Bill of Materials that can be exported on demand. Automated vulnerability scans run on every PR.
This matters because supply chain questions are now standard in every enterprise vendor review: "What is your process for identifying and patching vulnerable dependencies?" The acceptable answer is no longer "we update when we get around to it."
7. SSO and Access Controls Designed for Day 100, Not Day 1
Even if your first customer is a 10-person startup, design the access control model as if your tenth customer is a Fortune 500. That means:
- SSO-ready from the start (SAML or OIDC, not just email/password)
- Role-based access control with customer-configurable roles
- Audit trails on admin actions, visible in the product UI
- Session management and timeout controls
Retrofitting SSO onto a product that shipped with bespoke auth is one of the most painful migrations in software. Shipping with SSO-ready auth on day one costs almost nothing extra.
What Security Reviewers Actually Look For
After sitting on both sides of these reviews, the pattern is clear. Reviewers are not looking for perfection. They are looking for evidence of discipline. Can you answer their questions with specifics? Can you point at code and config? Can you show them logs and audit trails?
A scrappy team that can produce concrete answers passes reviews that a bigger team with vague answers fails.
When We Pull in Outside Experts
We are not a SOC 2 audit firm. When a client needs a formal attestation, we partner with specialized auditors and pen testers. Our job is to make their job easy by building the product so that the audit becomes a paperwork exercise instead of a remediation project.
A typical SOC 2 Type I readiness effort on a codebase we built from scratch: 4 to 6 weeks. On a codebase we inherited that was not built with these practices: 4 to 6 months.
The Bottom Line
Shipping fast and passing security reviews are not opposing forces. They look that way because most teams optimize for one or the other. If you start with the right IAM model, the right logging posture, and the right secrets handling, you are not slower. You are identical in speed and dramatically more defensible.
If you are staring at a vendor security questionnaire you cannot credibly fill out, or you are about to start a build and want to avoid that situation in the first place, get in touch. Our cloud consulting and infrastructure service covers both the remediation work and the "do it right from the start" work, and our SaaS development engagements bake all of the above in by default.