Healthcare Compliance as Platform at Array

The Problem

Array was strategically shifting from working through agencies and middlemen to direct relationships with pharma companies—our ideal customers. But enterprise pharma procurement was a different game. We faced rigorous security questionnaires, compliance audits, and legal reviews that our platform wasn't built to pass.

At the same time, new privacy regulations were emerging: GDPR in the EU and CCPA in California. Initially, it was blurry how these applied to our business—were we a data controller or processor? What did "right to be forgotten" mean for our learning platform? Our legal team was still figuring it out, and customers were starting to ask questions we couldn't confidently answer.

Additionally, pharma has unique compliance requirements for medical education content. Medical, Legal, and Regulatory (MLR) review is mandatory for any promotional materials, and our platform needed to support workflows that ensured:

• •Important Safety Information (ISI) appeared on every page with product claims
• •Version control ensuring only approved content was presented

The risk: We could lose Fortune 500 pharma deals we'd spent months pursuing. Worse, we could be building features that wouldn't actually satisfy compliance requirements because we didn't understand them well enough.

Discovery: Translating Legal Requirements into Product Reality

I partnered closely with our legal counsel and pharma customers to decode what these regulations actually meant for our platform. Legal documents are written for lawyers, not product teams. My job was to translate "data subjects have the right to request deletion of personal data" into "we need a process to retrieve and remove specific user data on demand."

For GDPR/CCPA:

Through iterative conversations with legal, we clarified:

• •What constituted personally identifiable information (PII) in our system? (Names, emails, engagement data, learning progress)
• •What rights did users have? (Access, deletion, portability, opt-out)
• •What did "consent" mean for our registration flows?
• •How long could we retain data, and for what purposes?

For SOC-2:

Working with our security team and legal counsel:

• •What security controls did enterprise customers expect? (Data encryption, access controls, audit logs)
• •How did we need to demonstrate compliance? (Annual audits, documentation, incident response plans)

For Pharma MLR Compliance:

Partnering with pharma customers and their legal teams:

• •How does MLR review workflow function? (Author → Medical → Legal → Regulatory → Approval)
• •What are ISI requirements? (Must appear on every screen with product information)
• •How do version control and approval trails need to work for audits?
• •What happens when content is rejected or needs revisions?

The insight: Compliance wasn't just about avoiding penalties—it was a product capability that unlocked enterprise deals. If we could confidently say "Yes, we're GDPR-compliant, SOC-2 certified, and support MLR workflows," procurement moved faster.

Building Compliance into the Platform

I worked in close partnership with my engineering counterpart to translate these requirements into technical architecture and product features.

1. SOC-2 Infrastructure Evolution

We evolved our engagement platform infrastructure to align with SOC-2 standards:

• •Data encryption (at rest and in transit)
• •Access controls and audit logging
• •Incident response procedures
• •Vendor risk management for third-party integrations

This wasn't a single feature—it was foundational platform work that touched everything. But it allowed us to move through enterprise procurement interviews confidently, with documentation to back up our claims.

2. PII Separation and Data Management

For GDPR/CCPA, the technical challenge was that PII was scattered throughout our data structures. User names, emails, and engagement data were intermingled with course content, analytics, and reporting.

I initiated a plan with engineering to:

• •Separate PII into distinct data structures that could be queried and deleted independently
• •Build a data retrieval process so we could fulfill "right to access" requests (give users all their data in a portable format)
• •Build a deletion workflow that removed user data while preserving aggregate analytics (we couldn't just delete a user ID and break all our reports)

This was architecturally complex. We needed to maintain data integrity while making specific user data retrievable and removable.

3. MLR Compliance Workflows

For pharma-specific requirements, we built:

Content Review System:

• •Multi-stage approval workflow (Medical → Legal → Regulatory)

ISI Management:

• •Template system ensuring ISI appeared on required pages
• •Dynamic ISI updates across all content when regulations changed

4. Seamless User Experience While Ensuring Compliance

Compliance requirements can create terrible user experiences if you're not thoughtful. I partnered with design to ensure:

• •Consent flows felt natural, not like legal obstacles (clear language, progressive disclosure)
• •Privacy controls were accessible but not intrusive
• •Registration remained frictionless while capturing necessary consents
• •MLR support as seamless part of the setup

The goal: Compliance should be invisible to users who aren't looking for it, and empowering for those who are.

Cross-Functional Orchestration

This work required constant alignment across:

• •Legal: To ensure our interpretation of regulations was correct
• •Engineering: To build the architecture that made compliance possible
• •Design: To make compliance features feel seamless
• •Sales: To articulate our compliance posture in procurement conversations
• •CS: To handle data access and deletion requests from users
• •Pharma customers: To validate MLR workflows met their regulatory needs

Results

We delivered a compliant, scalable platform that:

Business Impact

• •✅ Achieved SOC-2 certification (unlocking enterprise procurement)
• •✅ Met GDPR/CCPA requirements (data access, deletion, consent)
• •✅ Built MLR compliance workflows (differentiated from competitors)
• •✅ Unlocked Fortune 500 pharma deals that had been stalled in procurement
• •✅ Grew enterprise adoption as compliance became a competitive advantage

Platform Capabilities

• •✅ PII architecture supported future regulations (scalable foundation)
• •✅ MLR workflows became sellable feature (not just requirement)
• •✅ Audit readiness (documentation and trails for inspections)

Organizational Learning

• •✅ Compliance as product mindset spread across teams
• •✅ Legal-product partnership model became template for future work
• •✅ Sales confidence increased with a clear compliance story

Key Learnings

1. Compliance is a product capability, not a legal checkbox.
Reframing it this way helped the team see it as value creation (unlocking deals) rather than obligation (avoiding penalties). Compliance became a competitive advantage that sales could lead with.

2. Legal requirements need translation, not just implementation.
My job was to bridge legal language and technical reality. This required iterative conversations with legal counsel, not just reading documents. The product team couldn't build from regulatory text—they needed user stories and acceptance criteria.

3. Architecture matters more than features for compliance.
Separating PII into retrievable/deletable structures was foundational work that made all future compliance easier. Quick fixes would have created long-term debt. The MLR workflow architecture enabled us to adapt as regulations evolved.

4. Compliance can be invisible or empowering—your choice.
Thoughtful design meant users didn't feel burdened by consent flows, but those who cared about privacy had clear controls. MLR workflows integrated naturally into content creation, not as separate audit tasks.

5. Industry-specific compliance creates moats.
Building MLR workflows wasn't required for privacy regulations—it was pharma-specific. But it differentiated us from competitors and deepened customer relationships. Understanding industry nuances turns compliance from cost center to competitive advantage.

6. Cross-functional alignment is continuous, not one-time.
Regulations evolved. Our interpretation deepened. Sales needed updated positioning. MLR requirements changed with FDA guidance. This required ongoing communication, not a single kickoff. Product management of compliance is never "done."

7. Documentation is a product deliverable.
Audit trails, approval histories, and compliance reports aren't just for legal—they're features customers need. Treating documentation as first-class product work improved both compliance readiness and user experience.