For an internal developer portal in a regulated company, the goal is to give engineers and auditors a single trustworthy view of “what exists, who owns it, what risk it carries, and whether it is compliant right now.” The exact set depends on your regulations, but the portal should usually show data in these categories:

1) Service ownership and accountability

• Service name / description
• Business owner and technical owner
• Team / on-call rotation
• Support contacts
• Data owner / risk owner
• Criticality tier
• Dependencies and upstream/downstream services

2) Asset inventory

• Applications, APIs, microservices
• Infrastructure components
• Databases, buckets, queues, secrets stores
• Environments: dev / test / staging / prod
• Cloud accounts / subscriptions / projects
• Third-party SaaS integrations
• Libraries / runtime versions
• Source repositories and deployment pipelines

3) Data classification and data flow

• What kinds of data the service handles
• Data classification labels, e.g. public / internal / confidential / restricted
• Whether it processes:
  • PII
  • PHI
  • PCI
  • financial data
  • export-controlled data
• Data residency / region
• Retention period
• Data processing purposes
• Data flow diagrams or lineage
• Whether data is encrypted in transit and at rest
• Cross-border transfer indicators

4) Security posture

• Authentication mechanism
• Authorization model / access groups
• MFA enforcement
• Encryption status
• Secrets management status
• Vulnerability scan results
• SAST / DAST / dependency scanning results
• Container image scan status
• Patch levels and last update date
• Security exceptions / risk acceptances
• Open incidents and severity
• Pen-test findings and remediation status

5) Compliance controls and status

Show mapped controls with pass/fail/unknown status, for example:

• Access reviews completed on schedule
• Logging enabled and retained per policy
• Backups tested
• Disaster recovery tests completed
• Change management approvals in place
• Separation of duties checks
• Least privilege compliance
• Secure SDLC checks
• Privacy impact assessment completed
• Vendor risk assessment completed
• Records of training completion
• Policy acknowledgements
• Evidence linked to each control

6) Audit evidence

• Evidence artifacts and links:
  • tickets
  • approvals
  • screenshots
  • logs
  • reports
  • attestations
• Timestamp and evidence owner
• Evidence freshness / expiry
• Control-to-evidence mapping
• Audit trail of changes
• Who approved exceptions and when

7) Risk and exception management

• Open risks by severity
• Risk register entries
• Compensating controls
• Policy exceptions
• Exception expiry dates
• Remediation plans and due dates
• Escalation status
• Residual risk rating

8) Operational resilience

• SLOs / SLAs
• Uptime and error budget status
• Backup success / restore test results
• DR objectives: RTO / RPO
• Incident history
• Known service degradations
• Single points of failure
• Capacity / scaling risks

9) Change and release governance

• Approved release windows
• Recent changes and approvers
• Change freeze status
• Deployment frequency
• Rollback readiness
• Segregation of duties for production changes
• Emergency change markers
• CI/CD policy compliance

10) Third-party and supply-chain risk

• Vendor list and purpose
• Vendor criticality
• Contracts / DPAs / BAAs status
• Security review status
• SOC 2 / ISO cert links
• Subprocessor information
• Dependency health
• Open-source license compliance
• Provenance / SBOM data
• Signed artifacts / attestations

11) People and training

• Required training completion:
  • security awareness
  • privacy
  • compliance
  • secure coding
• Role-based training completion
• Certification status if relevant
• Access certifications / recertifications
• Joiner/mover/leaver status for privileged access

12) Policy and regulatory mapping

Map the service to applicable regimes, such as:

• SOX
• GDPR / UK GDPR
• HIPAA
• PCI DSS
• SOC 2
• ISO 27001
• GLBA
• FedRAMP
• MiFID II
• industry-specific internal policies

For each, show:

• applicable? yes/no
• scope reason
• controls required
• current compliance status
• last assessment date
• next review date

---

Recommended portal views

Service detail page

A “single pane of glass” for one service:

• owner
• classification
• controls
• evidence
• risks
• dependencies
• incidents
• exceptions

Compliance dashboard

At a portfolio level:

• services in scope by regulation
• controls passing/failing
• overdue evidence
• high-risk exceptions
• top noncompliant services
• remediation aging

Auditor view

A read-only, exportable view with:

• evidence packages
• immutable audit logs
• control mappings
• date filters
• attestation history

Engineering action view

Task-oriented:

• failed controls
• missing evidence
• upcoming expirations
• required approvals
• remediation tickets linked to owners

---

Important design principles

• Show only what is actionable and auditable.
• Avoid duplicating source-of-truth systems; link to them.
• Indicate data freshness for every field.
• Use role-based access control so sensitive compliance info is restricted.
• Keep a strong audit trail for changes and approvals.
• Support evidence expiration and recurring reviews.
• Make exceptions explicit rather than hiding them.
• Normalize control mappings so one control can apply to many services.

---

A practical minimum viable set

If you want a strong starting point, include these first:

1. Service owner and criticality
2. Data classification
3. Regulatory scope flags
4. Control status with evidence links
5. Vulnerability and incident status
6. Access review and change approval status
7. Risk exceptions with expiry dates
8. Last reviewed / next review dates

If you want, I can also help you design:

• a data model/schema for the portal,
• a dashboard layout,
• or a control catalog aligned to a specific regulation like SOC 2, ISO 27001, or PCI DSS.