Who Owns What

Shared responsibility, stated plainly: you own your application, and the university owns the platform-level things no individual builder should have to. This page lays out which is which, so you know before something breaks.

The split

You own (the builder)	OIT provides
Correctness of your code — it does what it claims, including the code you didn't personally type	Approved-tool contracts and data protection agreements, so using sanctioned tools keeps you inside policy by default
Data handling — the right sensitivity level in the right tools, synthetic test data, no Restricted data in AI, ever	Identity and access services (ND accounts, and Okta SSO where requirements apply)
Review and quality — human review, tests, and acting on scanner findings	Security tooling on the standard stack: static analysis, secret scanning, dependency review
Secrets — proper storage, and rotation if one leaks	Assessment of new tools, connectors, and skills — check with us before installing
Upkeep — dependencies patched, the app maintained or gracefully retired; apps don't stop being yours when they ship	Enablement: training, office hours, published skills and templates, and this guide
Your users — support, communication, and honesty about what your app does with their data	Platform services OIT operates (network, hosting where OIT-managed, enterprise systems your app may integrate with)

Where the line moves

The split above assumes a self-contained project. As your app takes on university resources — SSO, OIT-managed hosting, institutional data — some responsibilities shift toward OIT (platform operations, identity) while yours sharpen (meeting integration requirements, staying within the data agreement you signed up for). The lanes page shows how expectations scale; university resources covers the specific requirements.