Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →What has to be on file for every supplier, how data processing agreements and subprocessor disclosure actually work, and why most registers look green and evidence nothing.
A vendor register is not a list of suppliers. It is a per-supplier record of four things: what they do for you, what you owe them contractually, what independent assurance you hold and have read, and when you look again. The obligations should be derived from facts on the record, not kept as a hand-ticked checklist, because a checklist drifts and a derived list cannot. The failure mode is a register that shows all green while the company holds five SOC 2 reports nobody has read, no executed data processing agreements, and no recorded decision about the suppliers that did not need one. Related: startup vendor management and what vendor risk management is.
Three different audiences read your vendor register, and they want different things from it. An auditor wants to see that you identified the suppliers inside your system boundary, decided how much they matter, obtained something independent about their security, and looked at it again on a schedule. A customer's procurement or privacy team wants to know exactly who else touches their data, under what agreement, in which country, and how they find out when that changes. Your own engineering and finance teams want to know what you are paying for and what breaks if it goes away.
A spreadsheet with columns for vendor name, spend and a tickbox marked "DPA" answers none of those questions properly. It answers the first one badly, because a name and a tick do not say what the supplier does. It answers the second one not at all, because a subprocessor disclosure has to be published and versioned, not held internally. And it actively misleads on the third, because a tick recorded in March tells you nothing about whether the agreement it referred to still exists.
The useful mental model is that a vendor register holds facts, and everything else is derived from those facts. The facts are: does this supplier handle personal data on our behalf, are they inside the audited boundary, how critical are they to us, what assurance have they given us, and does that assurance carry exceptions. Every obligation follows from those. Derive the obligations and the register cannot drift, because the moment a fact changes the obligations change with it. Store the obligations as a checklist somebody maintains by hand and it will be wrong within a quarter, and nobody will know which quarter.
Start from the fields an obligation depends on rather than from the fields a procurement system happens to have. A row that carries spend, renewal date and account owner but not scope or data handling cannot generate a single compliance obligation, which is why finance-owned vendor lists are never usable as compliance registers without rework.
The minimum set that makes a register operable:
The single most useful field on the register is whether the supplier sits inside the system boundary you are audited on, and the important design decision is that it has three states rather than two. A supplier nobody has assessed yet is not the same thing as one deliberately placed outside the boundary. Only the first is a gap.
This matters because it decides what work exists. A supplier placed outside the boundary carries no questionnaire obligation, no assurance obligation, no rating and no reassessment cycle. If you collapse "out of scope" and "not yet decided" into one blank, you get a dashboard number that no amount of work can ever clear, and people stop trusting the dashboard. If you collapse them the other way and treat undecided as out of scope, you have quietly excluded suppliers from the program without anyone deciding to.
Deciding scope is a scoping conversation, not a data entry task. The test is whether the supplier could affect the security, availability or confidentiality of the system described in your audit scope. A cloud hosting provider is in. A design tool used to draw diagrams is out. A code repository is in. A recruiting platform is usually out of the security boundary but is still handling personal data, so it picks up privacy obligations without picking up audit ones. Those two things travel separately and a register that conflates them will over-work half your suppliers and under-work the other half.
Record the decision with a reason. "Out of scope: design tool, holds no customer data and has no production access" is a sentence an auditor reads and moves on from. An empty scope field is a sentence they ask about.
Criticality tiering gets confused with risk rating constantly, and the confusion produces registers where a well-run hosting provider is tiered low because they have a good SOC 2 report. That is backwards. Criticality answers one question: what happens to you if this supplier goes down, gets breached, or disappears. It is a property of your architecture and your contracts, not of their controls.
A workable four-tier scale reads like this. Low: we could switch or live without them for a while. Medium: losing them would hurt but not stop us. High: a production dependency, or they hold customer data. Critical: if they go down or get breached, so do we.
The reason to keep criticality separate from their security posture is that the two combine to produce the action. A critical supplier with a current SOC 2 Type II covering the service you buy needs a read of the report and a diary date. A critical supplier with nothing but a trust page needs a real conversation, possibly a contractual commitment, and a documented decision by someone senior enough to accept the residual risk. A low-criticality supplier with nothing needs a lightweight questionnaire at most. If criticality already has their security baked into it you cannot compute any of that.
Tiering also decides how much diligence is proportionate, which is what stops a vendor program collapsing under its own weight. A ten-question review of about ten minutes is proportionate for a low-criticality supplier. A twenty-five to thirty question review taking a knowledgeable person at the vendor around twenty-five minutes is proportionate for anything touching production systems or personal data. Nobody completes a two hundred question spreadsheet, and a questionnaire that is never returned tells you nothing at all.
A data processing agreement is the contract that governs a supplier handling personal data on your behalf. Under Canadian federal privacy law, Quebec's Law 25, the UK and EU regimes and most state-level US privacy laws, the organization that decides why and how personal data is processed remains accountable for it when it hands that data to someone else, and is expected to secure comparable protection by contract. The terminology differs by regime. The obligation to have something written down does not.
The determination is binary and belongs on the record: does this supplier handle personal data on our behalf, yes or no. If yes, terms are required. If no, terms are not required, and that is a recorded determination with a reason rather than an empty field. This is the part teams skip and it costs them, because an auditor reads a blank as an omission. "Not required: hosts our public marketing site, holds no personal data" is a complete answer. A blank is a question.
What the agreement itself has to cover is fairly consistent across regimes: the subject matter and duration of the processing, the nature and purpose of it, the categories of data and of data subjects, that the processor acts only on your documented instructions, confidentiality obligations on their staff, an obligation to implement appropriate security measures, terms governing their own use of sub-processors, assistance with data subject requests and with breach notification, deletion or return of the data at the end of the contract, and a right for you to obtain information demonstrating compliance.
In practice you will rarely draft one. Every serious SaaS supplier publishes their own, usually as a linked schedule that incorporates by reference into their terms of service. Reading theirs and deciding whether it is acceptable is the actual work. The clauses worth reading closely are the sub-processor terms, the security schedule, the breach notification window, the data location commitments, and the deletion terms on termination. TrazTech publishes its own data processing terms at traztech.ca/dpa, which is the shape of the thing your suppliers should be able to hand you on request.
A single "DPA signed" tickbox destroys information. It cannot distinguish a supplier nobody has looked at from one that genuinely does not need terms, and it cannot distinguish an agreement you have sent from one that came back countersigned. Six states carry the whole lifecycle without ambiguity.
Executed is the state people record loosely, and it should be the strictest. An agreement is only executed when the signed document is attached and the date the counterparty signed is recorded. A status of executed with no attached document is somebody's memory of a conversation. A document with no counterparty date cannot be placed in time, which matters the moment an auditor asks whether terms were in force during the observation window. If your register also keeps a simple signed-or-not boolean for reporting, derive it from those two fields rather than letting anyone set it by hand, so the two can never disagree.
One state deserves to be surfaced loudly: the contradiction where a supplier is flagged as handling personal data on your behalf and also marked as not requiring terms. Those two facts cannot both be right. Either the flag is wrong or the determination is. Left alone it sits in the register looking settled, and it is precisely the row a competent sampling approach is designed to find.
A subprocessor is a supplier that processes your customers' personal data as part of you delivering your service. Your hosting provider is one. Your transactional email provider is one. Your error monitoring service, if stack traces can contain user data, is one. Your payroll provider is not, because it processes your employees' data for you rather than your customers' data through you.
The distinction matters because subprocessors carry a disclosure obligation and other suppliers do not. Almost every enterprise data processing agreement you sign, including the ones you accept by clicking through your customers' paper, commits you to two things. First, maintaining a current list of subprocessors and making it available. Second, giving notice before adding a new one, with a window in which the customer can object. Thirty days is the most common notice period. Fourteen days appears in lighter agreements and some enterprise paper asks for sixty.
That second commitment is an operational obligation with teeth, and it is routinely broken by teams who have no idea they made it. An engineer adds a new observability vendor on a Tuesday. It is now processing customer data. The notice period started thirty days before that, which is to say it did not start at all, and the company is in breach of a term in every enterprise contract it has signed. Nobody notices until a customer's privacy team reads the subprocessor page and asks when Datadog was added.
The fix is procedural and cheap. Adding a supplier that will touch customer data requires the same approval step as a production change, and the approval step includes publishing the update and starting the notice clock. The subprocessor page needs a "last updated" date and, ideally, a way for customers to subscribe to changes, because "we published it" is a much better position than "we emailed some people" when a customer claims they were not told.
What goes on the published list is the supplier name, what they do for you in one sentence, and where they process the data. Not the agreements, not the contract values, not the security assessments. The list is a disclosure, not a data room.
Every supplier row needs a country, or a list of them, because three separate conversations depend on it. Your own privacy compliance depends on it, because moving personal data across a border engages transfer obligations in most regimes. Your customer contracts depend on it, because residency commitments are among the most commonly negotiated terms in enterprise SaaS agreements. And your sales process depends on it, because Canadian public sector, healthcare and financial buyers ask about data location early and treat a vague answer as a red flag.
In Canada, federal private-sector privacy law does not prohibit transferring personal information outside the country, but it holds the transferring organization accountable for the information while it is in a third party's hands and expects comparable protection to be secured by contract. It also expects the practice to be disclosed, which is why cross-border processing belongs in your privacy notice rather than only in your vendor register. Quebec's Law 25 goes further and requires an assessment before personal information is communicated outside the province, weighing the sensitivity of the data, the purpose, the protections in place and the legal regime at the destination. The practical consequence is that a Quebec-facing business needs a documented, dated assessment on file for its material cross-border suppliers, not just a country column. The privacy law finder is a reasonable starting point for working out which regimes you are actually in.
For the EU and UK the mechanism is contractual, usually standard contractual clauses incorporated into the supplier's data processing terms, sometimes supported by an adequacy decision or an approved certification framework. What you need on file is the mechanism the supplier relies on, not a legal opinion about it. If a supplier cannot tell you which mechanism covers your data, that is itself the finding.
The question to put to suppliers is narrower than "where is our data". Ask where it is stored, where it is processed, where support staff access it from, and whether they will commit contractually to a specific region. Those are four different answers and the last two are where the surprises live. A vendor storing data in a Canadian region while their support team accesses it from three other countries is a perfectly common arrangement and a perfectly reasonable thing for a customer to want to know about.
Buyers routinely treat every kind of security document as "they have SOC 2", which is how an unassessed supplier ends up marked as covered. The kinds are not equivalent and the register should record which one you actually hold.
A SOC 2 Type II report tests controls over a period, so it says something about whether they actually ran. It is the strongest thing most SaaS suppliers can hand you, and it is normally refreshed annually. A SOC 2 Type I report is an opinion that controls were suitably designed on a single date. It says nothing about whether they operated. An ISO 27001 certificate means an accredited body certified the management system, and the certificate typically runs three years with surveillance audits in between; the thing to check is the scope statement, because it is entirely possible to hold a genuine certificate whose scope does not include the service you are buying. A PCI DSS attestation of compliance validates a named scope. A HIPAA attestation or business associate agreement is a contractual commitment, not an audit. A penetration test report is an independent test on a date, and the follow-up question is always whether the findings were fixed and retested. A public trust page is marketing. It is a starting point for a conversation, not assurance.
Record four things per report: which kind it is, the period it covers, when it expires, and whether it carries exceptions. The period matters because a Type II that ended twenty months ago is not current assurance, whatever the supplier's trust page says today. Expiry matters because reports lapse silently and the gap between one report's period end and the next one's period start is the window your customers will ask about, which is what bridge letters exist to cover. There is a good explainer on those at what a SOC 2 bridge letter is.
The state that should make someone uncomfortable is the one where a supplier claims a report and you have never seen it. A claim with no document on file is not assurance, and a register that shows it as green is lying to you specifically. Ask for the report under NDA. A supplier that holds a report and will not show it is effectively unaudited from your side, and that is a legitimate input to a buying decision.
Collecting a report is not the control. Reading it is. The obligation is to record that somebody read it, who, when, and what they concluded, and that record is what an auditor samples. This is the single most commonly skipped step in vendor management, and it is the reason a register can be entirely green while the company has effectively done nothing.
If the report carries exceptions, the record has to go further. List each exception, and say whether it affects the service you consume and what you concluded about it. An exception in a control the supplier operates for a product line you do not use is a defensible "no impact", provided somebody wrote that down. An exception in the access management controls of the service holding your production data is a risk you have now accepted, and the acceptance needs an owner and a date.
Service auditor reports also list complementary user entity controls: the things the supplier expects you to do at your end for their controls to work as described. Enabling multi-factor authentication on the accounts you hold with them, reviewing your own administrative users, configuring their encryption options, restricting access by IP. Until those are mapped against your own controls, it is not clear who covers them, and the honest answer is often nobody.
Mapping them is a mechanical exercise: list the complementary controls from the report, name the control at your end that covers each one, and note the ones that are not covered. That last list is a small, high-value backlog. It is also one of the more impressive things you can put in front of an auditor, because it demonstrates you read the report rather than filed it.
Vendor assurance is period evidence. It only exists if it was produced across the window, which means the register has to show a series rather than a snapshot. An annual cycle is the norm for suppliers inside the audited boundary, aligned to the supplier's own report cycle so that you are reviewing a fresh report rather than the same one twice.
A workable cadence by tier: critical and high-criticality suppliers annually, with the review scheduled for the month after their report period normally ends. Medium annually or every eighteen months, lighter in scope. Low on a rolling basis or on contract renewal only. Any supplier at all when something changes materially: a new data type flows to them, they announce a breach, they are acquired, or they change the region their service runs in.
Set the next review date explicitly on the row. A register with no review dates has no cadence, only intentions, and "we review vendors annually" as a policy statement with no dated records behind it is a finding rather than a control. Overdue reviews should be visible, and the count should be a number the vendor owner is asked about, not a number that lives on a dashboard nobody opens.
One structural point: the reassessment obligation belongs only to suppliers inside the boundary. Applying it to every supplier produces a permanently red register, which trains everyone to ignore it. Scope first, then cadence.
The requests are predictable enough to prepare for. In a typical enterprise security review of a Canadian SaaS vendor, the vendor management portion asks for: your current subprocessor list with purposes and locations; confirmation that you have data processing terms with each subprocessor; your process for assessing new suppliers before onboarding them; how you are notified of a subprocessor breach and how quickly you would notify them; how much notice you give before adding a subprocessor and how a customer objects; where their data will be stored and processed, including support access; and evidence that you review suppliers periodically.
Every one of those is answerable in a sentence if the register holds the facts, and unanswerable if it does not. This is the practical argument for the register that people actually respond to: it is not primarily an audit artefact, it is the thing that lets you answer a procurement questionnaire in two hours instead of two weeks. The vendor security questionnaire guide covers the receiving end of that in more detail.
Two requests deserve advance thought because the answers are commitments. When a customer asks for the right to audit your suppliers, the normal answer is that you will provide the supplier's report under NDA rather than grant a direct audit right, because you cannot grant what you do not have. When a customer asks for a contractual veto over new subprocessors, understand that agreeing to it means a single customer can block a piece of your infrastructure roadmap. The standard middle ground is notice plus a right to object plus a right to terminate if the objection cannot be resolved.
The register that looks green because the boxes were ticked. This is the canonical one: a company arrives at fieldwork holding five SOC 2 reports nobody has read, no executed agreements at all, and a register that shows every row complete because someone ticked "assurance obtained" when the PDF landed in a shared drive. Every individual tick was placed in good faith. Collectively they evidence nothing.
The blank that reads as an omission. Suppliers with nothing recorded in the data processing field, because they genuinely do not need terms and nobody wrote that down. To the person reading the register this is indistinguishable from a supplier nobody assessed.
The contradiction nobody resolves. Personal data flag set, data processing terms marked not required. It sits there looking settled.
Assurance that expired quietly. Reports have end dates, certificates lapse, and nothing in your environment fires an alert when a supplier's SOC 2 period ends. Without an expiry field and something watching it, the register reports a state that stopped being true months ago.
Scope creep in reverse, where the register accumulates every SaaS subscription the company has ever bought and becomes a two hundred row list with no tiering. Nobody can work a two hundred row list, so nobody does, and the twelve rows that mattered are buried in it.
The undisclosed subprocessor. Added by an engineer, live in production, absent from the published list, in breach of contractual notice terms nobody remembers signing.
The register that only exists in the compliance tool. If adding a supplier to the company happens in procurement or in a credit card statement and adding one to the register is a separate manual act, the register is always behind. The two events have to be the same event.
Build the initial register from evidence rather than memory. The reliable sources are the corporate card and accounts payable ledger for the last twelve months, your identity provider's list of connected applications, your cloud provider's marketplace subscriptions, and your DNS and email records. Every one of those finds suppliers the others miss. Ask each team lead to review the assembled list rather than to produce one from scratch, because reviewing a list is a five minute task and producing one is a task that never gets done.
Then triage in one pass: scope decision, criticality, personal data flag, subprocessor flag. That single pass usually reduces a hundred-row supplier list to fifteen or twenty rows that carry real obligations, and getting to that number is what makes the program sustainable. Record the out-of-scope decisions with reasons as you go; they are cheap to write at the time and expensive to reconstruct later.
Work the obligations by tier, critical first. For each in-scope supplier: request their current report under NDA, record what came back with its period and expiry, read it and write down what you concluded, map the complementary user entity controls, confirm the data processing position and attach the executed agreement, and set the next review date. That is roughly thirty to sixty minutes per supplier for the first pass and considerably less on subsequent cycles.
Finally, wire the register into the two events that change it. Onboarding a supplier creates the row and forces the scope and data questions before access is granted. Offboarding one revokes access, confirms data deletion or return under the terms you agreed, and marks the row inactive rather than deleting it, because an auditor sampling a past period may need the supplier who was in the boundary in March even though they are gone in September. Registers fail at the edges, not in the middle.
| Item | Required when | What actually counts as satisfying it |
|---|---|---|
| Scope determination | Every supplier | In, out, or not yet decided, recorded explicitly. An out-of-scope decision carries a one-line reason. A blank is a gap, not an answer. |
| Criticality tier | Every in-scope supplier | Low, medium, high or critical, describing your dependency on them rather than the quality of their security program. |
| Data processing terms | Any supplier handling personal data on your behalf | The executed agreement attached, plus the date the counterparty signed. Where terms are not required, a recorded determination with the reason. |
| Subprocessor flag and disclosure | Any supplier processing customer personal data | On the published subprocessor list with name, purpose and processing location, with a last-updated date on the page. |
| Independent assurance | High and critical in-scope suppliers | The actual report or certificate on file, with kind, period covered and expiry. A claim with no document is not assurance. |
| Evidence the report was read | Every report on file | A dated record naming who reviewed it and what they concluded. If the report has exceptions, each one addressed individually. |
| Complementary user entity controls mapped | Every service auditor report on file | A list of the controls the report expects you to operate, with the control at your end that covers each, and the gaps named. |
| Security questionnaire | In-scope suppliers with no independent report | A completed, dated response with a reviewer conclusion. Lightweight for low criticality, full review for anything touching production or personal data. |
| Processing locations | Any supplier handling personal data | Storage location, processing location and support access location, by country, plus whether they will commit contractually. |
| Cross-border assessment | Quebec-facing businesses, material transfers | A dated assessment weighing sensitivity, purpose, protections in place and the legal regime at the destination. |
| Next reassessment date | Every in-scope supplier | An explicit future date with a named owner. Annual for high and critical, aligned to the supplier report cycle. |
| Offboarding record | Every supplier you stop using | Access revoked, data deletion or return confirmed under the agreed terms, row marked inactive rather than deleted. |
No. Data processing terms are required for suppliers that handle personal data on your behalf. A hosting provider running your production database needs them. A supplier that holds no personal data does not. What you do need for every supplier is a recorded determination one way or the other, with a reason attached when the answer is no. The reason to record the negative case is that an auditor reads an empty field as something nobody looked at, which is indistinguishable from an omission. A one-line note saying the supplier holds no personal data and terms are therefore not required closes the question permanently.
A vendor is anyone you buy from. A subprocessor is specifically a supplier that processes your customers personal data as part of you delivering your service to them. Your hosting provider, your transactional email service and often your error monitoring tool are subprocessors. Your payroll provider handles personal data but is not a subprocessor of your customers data, because it processes employee data for you rather than customer data through you. The distinction matters because subprocessors carry a public disclosure obligation and a contractual notification obligation before you add new ones, and other suppliers do not.
Whatever your customer contracts say, which is usually thirty days. Fourteen appears in lighter agreements and sixty appears in some enterprise paper. The obligation is one you agreed to, typically in the data processing terms attached to your customer agreements, and it is routinely broken by companies that have no idea it exists. The practical implication is that adding a supplier which will touch customer data has to be an approved change with a lead time, not something an engineer can do on a Tuesday afternoon with a corporate card.
No, and this is the most common gap in vendor management. Collecting the report is not the control. The control is reading it and recording what you concluded, with a date and a named reviewer. If the report carries exceptions, each exception needs an individual conclusion about whether it affects the service you consume. The report also lists complementary user entity controls, which are the things the supplier expects you to operate at your end, and those need mapping against your own controls. A register full of unread PDFs evidences that you can download files.
Annually for suppliers inside your audited boundary, particularly the high and critical ones, ideally scheduled just after the month their own report period normally ends so you are reviewing something current. Medium criticality can run annually or on an eighteen month cycle with a lighter scope. Low criticality suppliers can be reviewed on contract renewal. Separately from the calendar, reassess any supplier when something material changes: a new category of data starts flowing to them, they disclose a breach, they are acquired, or they change where the service runs.
Generally yes, but you remain accountable for it. Canadian federal private-sector privacy law does not prohibit cross-border transfers, and instead holds the transferring organization responsible for securing comparable protection by contract and for being transparent about the practice, which means it belongs in your privacy notice as well as your vendor register. Quebec Law 25 is stricter and expects an assessment before personal information is communicated outside the province, considering the sensitivity of the information, the purpose, the protections in place and the legal framework at the destination. If you have Quebec customers or employees, you want those assessments dated and on file for your material suppliers.
Publish the supplier name, one plain sentence about what they do for you, and where they process the data. Add a last-updated date and a way for customers to be notified of changes. Keep everything else internal: the agreements themselves, contract values, your security assessments, questionnaire responses, criticality tiers and any findings. The published list is a disclosure so customers can exercise the rights they negotiated. It is not a data room, and the material that belongs in a data room goes out under NDA on request.
Triage before you do any diligence. One pass across the whole list answering four questions per row, scope in or out, criticality, does it handle personal data, is it a subprocessor, will typically reduce two hundred rows to fifteen or twenty that carry real obligations. Record the out-of-scope decisions with reasons while you are there, because they are cheap to write in the moment and expensive to reconstruct in nine months. Then work the surviving rows by criticality, critical first. Trying to apply full diligence to two hundred suppliers is how vendor programs stall permanently.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We scope the supplier population, triage it down to the rows that carry real obligations, and leave you with a register that answers a procurement questionnaire instead of raising one.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.