Security and data handling

Who is responsible for what

• Your institution owns the data, decides what I may do with it, and can end my access at any time.
• I act on your instructions under a written agreement. For student records, that means working as a contractor under your direct control, with use limited to the purpose you set, as FERPA’s school official exception describes. I complete FERPA and information security training every year.
• For financial aid data, the Gramm-Leach-Bliley Act’s Safeguards Rule also applies to your institution, and it asks you to hold service providers to appropriate safeguards by contract. I expect to see those terms in our agreement.
• Microsoft Azure is the cloud provider when an integration is hosted. Microsoft secures its data centers and platform. It does not secure how a solution built on it is configured; that part is mine, and yours where the subscription is yours.

What data I handle, and what I do not

• As little as the job needs. Most integration, reporting and automation work can be designed and tested on structure, rules and test data. Real records are used only where the work requires it.
• Only for the work you asked for. Your data is not used for any other purpose, not shared, not sold, and not used to market anything.
• Not in email. I ask clients never to send student records or passwords by email, and I do not send them that way either.
• Not kept afterward. Wherever possible I work inside your own Microsoft 365 or Google Workspace, so your records remain in your tenant, and when an engagement ends you switch off my account and nothing stays with me. Anything I did hold outside it is returned or destroyed, and I confirm that in writing.

AI tools and your data

I use AI agents in my work, and I am specific about what they may touch.

• Your decision, made first. Whether an AI tool sees your records at all, and which ones, is settled with you in writing before work starts. Where the answer is no, the agent works on structure, rules, code and counts, and the record-by-record work is done by ordinary code inside your environment.
• Production is read-only to agents. Where you have agreed to it, an agent reads a live system with read tools: read-only credentials wherever the system offers them, and rules in the tooling that stop a write before it runs. Changes are applied by a person.
• No training on your data. Where student or institutional records are involved, I will use an AI service only under terms that bar the provider from training its models on that data, and I will show you those terms before work starts.
• A record is kept. Agent work leaves a record of what was read, what was proposed and what was checked.

More on the method is on the approach page.

Where the work runs

In your environment, by default. I connect the way your security team prefers and work inside the systems and test environments you already have.

In Azure, when an integration needs hosting. There are two arrangements, and you choose:

1. Your Azure subscription. You own the environment, the data and the bill. I build and manage it with the access you grant.
2. A dedicated environment that I run for you. Set aside for your institution alone and isolated from every other client, in a United States region. The agreement between us sets out what it may hold.

How a hosted integration is built

• Encryption of data in transit and at rest.
• Multi-factor authentication on every administrative account.
• Least access. Each component can reach only what it needs. Services identify themselves with managed identities instead of stored passwords, and any secret that must be stored is kept in a key vault.
• No second copy of your student database. An integration passes records along. It keeps only what it needs to do that reliably.
• Logging and alerts. What moved, when, and whether it arrived is recorded. A failure alerts a person.
• Everything defined in code, so the environment can be reviewed, rebuilt and handed over.

If something goes wrong

• I tell you as soon as I know, and within the time our agreement sets. I propose no later than 24 hours, so that you can meet your own reporting duties.
• You get the facts as I have them: what happened, what data was involved, what has been done.
• Before a project starts I will walk your security office through how I would respond to an incident, and the notification terms go into our agreement.

If I am not available

DataZak is a one-person practice, and it is fair to ask what that means for you. Three things are built in from the start:

• You can take it over. In your own subscription you are the owner. In a dedicated environment that I run, the agreement gives you the right to take it over, and the steps to do so are written down.
• Runbooks. How it works, how to restart it and how to switch it off are written down and delivered to you.
• The code is yours. Everything I build for you is handed over, so another engineer can take it on.

What your security office can ask me for

• Answers to your vendor security questionnaire, including the HECVAT used across higher education
• My signature on a data security or data protection addendum, once we have agreed its terms
• An architecture and data-flow diagram for the specific work, with the list of data elements
• Proof of insurance, where our agreement requires coverage

What I do not claim

• No SOC 2 report. I am a solo practitioner and have not been through that examination. Microsoft publishes audit reports for Azure itself; those cover Microsoft’s controls, not mine.
• No “FERPA certified.” There is no such certification. FERPA compliance belongs to your institution and to the agreement we sign.
• No absolutes. Nobody honest promises that a system is perfectly secure. I can show you exactly how yours is built and who can reach it.

Questions

Security questions and reports of a problem are welcome at the address on the contact page.

Last updated October 17, 2026.