Cleared for Launch: Ahead of the framework by design – Part 1

One Intake, Five Disciplines

How New Relic built a unified review system — designed from scratch around the customer, and around the frameworks that protect them.

Every enterprise software company has a version of the same story. A product team ships something new. A customer's security officer picks it up in an audit, or reads a line in a release note, or asks a question in an annual review that nobody on the vendor side anticipated. The vendor scrambles. Legal drafts a response. Security reviews the architecture. Compliance checks the certification. Somewhere in the middle, IT weighs in on whether the new thing talks to the old things correctly. The procurement team wonders if there was a contract somewhere that should have governed this.

Each of those functions had a queue. Each queue had its own process. The answer the customer eventually receives is a composite of five separate opinions assembled under time pressure, and the seams between them show.

New Relic set out to close the seams. What came out the other side is a system called STAR — System, Tooling, and Architecture Review — and the story of how it was built is a story about what happens when you start with the customer's problem instead of the company's org chart.

Where it started

The original logic was simple, and it was customer-first.

New Relic operates under some of the most demanding customer and regulatory requirements in enterprise SaaS. Our customers are the engineers, operations teams, and security officers responsible for keeping critical infrastructure running. Many of them operate under HIPAA, FedRAMP, SOC 2, ISO 27001, GDPR, CCPA, and a proliferating shelf of state and privacy laws simultaneously. When these frameworks and laws set requirements for a vendor, they do not evaluate one function at a time. They want to know: does this vendor treat security, legal, compliance, and privacy as a unified discipline, or as a collection of boxes to check?

The question is reasonable. The customer-facing consequence of a security gap, a compliance lapse, a contractual ambiguity, or a privacy violation is identical regardless of which internal team failed to catch it. From outside, it is simply a failure of trust.

But there is a second half to that customer reality. By ensuring our internal teams treat these frameworks as a unified discipline, we can ultimately provide you, the customer, with a friendly, expedient answer for your own compliance needs. Instead of passing you fragmented responses from different departments, our Customer Trust team leverages our collective STAR data to deliver a cohesive, comprehensive answer. This customer-first approach is designed to radically simplify and accelerate your procurement process.

That customer reality was the genesis of the SLC review function at New Relic — Security, Legal, and Compliance, together, accountable as a single team for the health of every material change to the New Relic ecosystem. Not a committee. Not a sign-off chain. A team, designed to ensure that the questions customers ask — and the questions regulatory frameworks require us to answer — are addressed not in sequence but in concert.

(For those who track such things: yes, the structure New Relic operates maps onto what governance frameworks call a Change Advisory Board. We satisfy that requirement. Internally, we call it the SLC review team, because that is what it is.)

The industry default, and why it fails

To understand why this matters, it helps to understand what most companies do instead.

The standard model at enterprise scale is departmental separation: Security owns the security review. Legal owns the legal review. Compliance owns the compliance review. IT owns the IT review. Procurement owns the vendor intake. Each function has its own ticket queue, its own intake form, its own timeline, and its own definition of what a "complete" submission looks like.

A product team launching something new navigates this by filing multiple requests — often simultaneously, hoping for parallel progress — and then waits. Security finishes and passes the baton to Legal. Legal finishes and passes it to Compliance. Compliance surfaces a question that has implications for the architecture Security already approved. Now there's a meeting. The meeting produces a revised assessment. The revised assessment goes back to Legal. Launch is three weeks later than anyone planned, for a set of concerns that, had all three functions been in the same room at the start, would have been resolved in the first conversation.

This pattern has a name in software development: waterfall. We retired it from engineering for good reasons twenty years ago — sequential stages, late error discovery, expensive course corrections. Most companies retained it in review. We decided not to.

The other consequence of departmental separation is redundancy. Each function asks the same baseline questions in their own language. A product team submitting to five queues fills out five forms that all, somewhere, ask some version of: What data does this touch? Who has access? What are the third-party dependencies? The answers are the same each time. The work of gathering and documenting them is repeated each time. The submitter's experience is friction, and friction means reviews happen later in a launch cycle than they should, when the cost of changing course is higher.

The design choice: one door

STAR is built on a different premise. There is one door.

Every material change at New Relic — a new product feature, a modification to an existing service, a new third-party tool under evaluation, a vendor renewal, a request for a local software exception — enters through a single JSM portal. A refined set of intake questions routes the request automatically. If the request involves new tooling or vendor procurement, IT and the Vendor Management Office are pulled in. If it involves a change to the product architecture, the SLC review team picks it up. If it involves both, both tracks open in parallel on the same parent record.

The request types in STAR cover the full spectrum of what a company like New Relic does, including:

1. Software or Tool Related Engagements — POCs, purchases, renewals
2. Non-Software Related Engagements — professional services, events, tangible items
3. SLC General Requests — advisory support outside the standard tracks
4. New Product Launch or Change to Existing Feature
5. Local Software Requests

From the submitter's perspective, this is one form, one ticket, one status. There is no second form for the procurement piece, no separate IT ticket to open, no compliance questionnaire to send separately. STAR routes the work.

From the reviewer's perspective, this is complete context available on day one. When the SLC review team opens a ticket, they see — in the same record — the design document, the threat model, the data flow diagram, the linked code repositories, the vendor's security posture if there is one, and the roadmap epic it ties to. No reconstruction from email threads. No waiting for a follow-up to surface the architecture diagram. Everything the review needs, in the system the company already uses to manage its work.

Designed in Jira, on purpose

That last phrase is the one worth sitting with: the system the company already uses to manage its work.

Most organizations that take governance seriously invest in a GRC platform — Governance, Risk, and Compliance — a dedicated system that lives separate from the engineering toolchain, purpose-built for audit trails, regulatory reporting, and structured questionnaire workflows. GRC platforms are coherent answers to a real problem. They are also a second system that every engineer, product manager, and product reviewer has to cross into in order to engage with the review function.

New Relic built STAR in Jira. Not integrated with Jira — in Jira. The intake form lives in Jira Service Management. The SLC review ticket is a Jira ticket. The Security, Legal, and Compliance subtasks are Jira subtasks on the same parent. The roadmap epic, the design doc, the code repo, the parent initiative — all linked natively. The status dashboard the review team works from on Tuesday is a Jira dashboard, the same interface used to track engineering work everywhere else in the company.

This is a design decision, not a tooling convenience. Engineers live in Jira. Product managers live in Jira. The roadmap lives in Jira. When the review lives there too, the distance between reviewers and the people whose work they're reviewing collapses. A security comment lands in the engineer's existing workflow, not in a portal they visit once a quarter. A design question gets answered in the thread where the design is being discussed. The review team doesn't receive translated summaries of what's happening in engineering — they see what's happening in engineering, in the same tool, in real time.

The consequence is cultural as much as operational. In companies where governance lives elsewhere, review teams become a gate at the end of the process — encountered reluctantly, late, under time pressure. In a company where governance lives in the same system, review teams can be present earlier, when there is still time to shape a design rather than approve or reject it after the fact.

What reviewers see, when they need to see it

Security reviewers and Legal reviewers and Compliance reviewers look at the same tickets, with the same context, at the same time. When a question in the compliance lane has implications for the security assessment, the two reviewers are in the same conversation. When a legal question would change the architecture, the architecture is visible in the record being discussed. Security, Legal, and Compliance team members actively work together in multiple channels: to stay aligned within the entire security, legal, and compliance group; to stay aligned among the team members assigned to the same STAR ticket; and with product and engineering teams so everyone’s aligned on the latest developments and discuss relevant facts needed to make a decision. Additionally, every Tuesday, the SLC review team formally meets collectively to walk the escalations. The meeting is not a status report — it is a working session that helps everyone align on strategic approaches and collective best path forward for our product and engineering teams. 

Because of our internal alignment and approach, this is where the design most clearly serves the customer's original question. The concerns your security officer raises in a questionnaire — How are changes reviewed? Do Security and Compliance see the same information? Who has accountability for a feature that touches HIPAA and GDPR simultaneously? — have the same answer: the SLC review team sees it together in the same Jira record.

Submitters, for their part, see one dashboard. One view of where every open request stands, across every review track. Not one status in the security queue and a separate status in the procurement system and an email chain with Legal. One record, with parallel subtasks visible, moving forward or surfacing blockers as they arise.

This simplicity is not an accident. It is the direct consequence of designing for the customer's experience of trust, and then working backwards into the operating model that delivers it.

The frameworks keep moving

The case for the design does not rest on the past. It rests on what happens next.

The regulatory frameworks governing enterprise software are not stable. The EU AI Act is now law and its implementation is ongoing. State privacy laws are proliferating faster than any single compliance function can track independently. FedRAMP authorization requirements continue to expand. Customer security questionnaires are longer and more specific each year, and they are increasingly focused on AI — on whether vendors use customer data to train models, on how prompt injection risks are assessed, on what controls exist when an AI agent can act in a customer environment.

A review function built on five separate queues, each tracking its own regulatory domain, will struggle to answer those questions coherently — because the questions don't respect the departmental boundaries the queues were built around. A review team that meets together, with shared context, coordinated in a single system designed to accommodate new tracks as new requirements emerge, is designed to answer them.

The remaining posts in this series open the review itself. Next: what the artifact bar actually looks like, how the LP → PP → GA gates work in practice, and what distinguishes a review that ends in approved with remediation required from one that ends in not approved. After that, a look at how the same team and the same funnel handle vendor procurement — the tools we consider using, and the ones we do not. And the final post is about AI: not as a special case that required us to build something new, but as the case that proves we had already built what was needed.

For now, the frame is this: STAR was not designed because New Relic wanted a better compliance posture. It was designed because New Relic's customers deserved a vendor that treated Security, Legal, and Compliance as a single team — meeting together, working in the open, coordinated by design. By streamlining our own internal processes, our Customer Trust team can provide you the simple-to-understand, unified answers you need to trust New Relic.

One intake. Five disciplines. That is where it begins.