We run SOC 2, ISO 27001 and the rest of the compliance stack for startups and SMEs, and the security testing that sits behind it. The first call is free, and we will tell you if you are not ready to start yet.

Book a free call

Track record

Who is actually doing the work

Published CVEs, including a CVSS 9.1

Controls taken from nothing to a passed SOC 2 Type II

Zero

Exceptions on that Type II report

20+

Penetration testing engagements delivered

Published vulnerability research

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.

A SOC 2 Type II built from nothing

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.

$posts_content['customer-sent-security-questionnaire-no-answers'] = '

Direct answer: Answer it honestly, including the gaps, and attach a dated remediation plan for anything you cannot answer yes to. Buyers reject vendors for inconsistency far more often than for immaturity. An honest "not yet, here is when" survives review. An invented yes fails the moment somebody asks for the evidence behind it.

The first thing to understand

A security questionnaire is not a test you pass or fail on the spot. It is a risk file. Somebody on the buyer side has to write a recommendation, and they need enough to justify it internally. What kills deals at this stage is not a weak control, it is an answer that cannot be backed up, because that turns a technical review into a trust problem.

What to do in the first 48 hours

Read the whole thing before you answer anything. Questionnaires repeat themselves, often asking the same control three ways across different sections, and answering them in order produces contradictions that a reviewer will find. Group the questions by subject first: access, data handling, infrastructure, vendors, incident response, people.

Then sort every question into one of three buckets. Things you do and can evidence. Things you do but have never written down. Things you do not do. That third bucket is where founders panic, and it is usually the smallest of the three.

Most early companies are further along than they think. You almost certainly have access control, because you use SSO. You have encryption, because your cloud provider does it by default. You have backups. What you do not have is any of it written down, which is a documentation problem rather than a security one, and it is much faster to fix.

How to answer the ones you cannot answer yes to

Write what is true now, then what changes and by when. "We do not currently run quarterly access reviews. We have scheduled the first for 30 September and will provide the completed record." A reviewer can work with that. It gives them something to write down and a date to hold you to.

Never answer yes to a control you cannot produce evidence for. The follow-up request is standard, and being unable to answer it is worse than the original no, because now the reviewer has to wonder what else was overstated.

What the questionnaire is really telling you

If a buyer sent a long questionnaire, you have crossed into a segment that will keep asking. The next deal will ask too, and probably for a SOC 2 report rather than a spreadsheet. The questionnaire is early warning that the answer needs to become a standing asset instead of a fire drill every quarter.

That is the actual decision in front of you. Not "how do I get through this document", but "how many more of these am I going to answer by hand before I put a report and a trust page in front of them instead".

What good looks like six months later

Companies that get this right end up answering questionnaires in under an hour, because the underlying answers exist once and get reused. They have a written policy set, an evidence store, and either a SOC 2 report or a clear date for one. The questionnaire stops being an event.

We do this two ways. Security Questionnaire Help gets the document in front of you completed and defensible when a deal is waiting. Trust Center Setup puts the answers on a page you can send instead, which is what stops the next one arriving as a spreadsheet.

'; $posts_content['buyer-asked-for-information-security-policy'] = '

Direct answer: They want a short, dated, signed document that says how you protect their data and who is accountable for it. They do not want a fifty-page manual. You can produce a defensible version in about a week, but a template downloaded and rebranded will fail the first follow-up question, because you will not be doing what it says.

What they are actually checking

The request is rarely about the document. A reviewer is checking three things: that somebody owns security, that there are rules people are expected to follow, and that the rules match how the company really operates. The document is just the artefact that proves it.

This is why a generic template is dangerous. It will confidently claim you run annual penetration tests, maintain a formal risk register and hold quarterly management reviews. If you do not do those things, you have handed the buyer a document that contradicts your own answers, and you have created a problem that did not exist before you sent it.

What the document needs to contain

A named owner, with a real job title. Scope, meaning which systems and which data. How access is granted and removed. How data is classified and handled. What happens during an incident and who declares one. How you assess vendors. A review date and a signature.

That is genuinely most of it. Policies that stay this size get read, followed and kept current. Policies that run to fifty pages get written once, never opened, and fall out of date within a quarter, which an auditor will notice immediately.

Write it to match reality, then improve reality

The correct order is to document what you actually do today, however modest, and then raise the bar deliberately. If access reviews happen when somebody remembers, write that you will run them quarterly starting on a specific date, and then run one. A policy describing a company you intend to become is not a policy, it is a liability.

Where this leads

One buyer asking for a policy usually means the next will ask for a policy set, and the one after that will ask for a SOC 2 report that proves the policies operate. Writing the first policy in isolation is fine. Writing eleven of them by hand, one deal at a time, is not.

If you want the set built properly rather than assembled under pressure, that is what compliance readiness covers, and our security policy generator is free if you would rather make a start yourself.

'; $posts_content['customer-wants-proof-of-penetration-test'] = '

Direct answer: Most buyers accept an attestation letter from the testing firm, stating scope, dates, methodology and that findings were remediated. They do not need the full technical report, and sending it is usually a mistake because it hands a third party a list of your weaknesses.

The three things they are checking

Whether the test was done by somebody independent, whether the scope covered the system they are buying, and whether you fixed what was found. A report that covers your marketing site when they are buying your API satisfies none of it, even though it is technically a penetration test.

Recency matters too. Twelve months is the usual expectation, and many enterprise reviewers will not accept anything older without an explanation.

Why the attestation letter is the right artefact

The full report contains reproduction steps for anything not yet fixed. Circulating that through a buyer\'s procurement inbox, where it gets forwarded and stored, is a real risk with no upside. A good testing firm will issue a summary letter designed for exactly this, and buyers are used to receiving one.

If a buyer insists on the full report, redact the reproduction detail for open findings, or share it under NDA through a controlled channel. Pushing back here is normal and does not read as evasive when you offer the attestation instead.

If you have never had a test done

Say so, and give a date. "Our first external test is scheduled for November with remediation to follow" is a workable answer. What does not work is a vulnerability scan presented as a penetration test. Reviewers can tell, because scanner output looks like scanner output, and being caught inflating this is worse than admitting the gap.

A scan is automated and finds known issues. A test is a person chaining findings together and proving what an attacker could actually reach. Both are useful. They are not interchangeable, and the questionnaire is asking for the second one.

Scoping it so it satisfies the buyer and the auditor

If SOC 2 or ISO 27001 is anywhere on your roadmap, scope the test so its report doubles as audit evidence. That means covering the production system in the audit boundary, timing it inside the observation window, and having the findings tracked to closure somewhere an auditor can see. Done properly you buy one test and satisfy two requirements.

That is how we scope compliance penetration testing, and prices are published on the pricing page so you can budget before booking a call.

'; $posts_content['cyber-insurer-asking-about-security-controls'] = '

Direct answer: Treat the application as a contract, not a form. Insurers price on a small set of controls, mainly multi-factor authentication, backup isolation, endpoint detection and a tested incident response plan. Overstating any of them can void a claim at exactly the moment you need it.

Why this form is different

A customer questionnaire affects a deal. An insurance application affects whether you get paid after an incident. Insurers have declined claims on the basis that the applicant said they had MFA everywhere when they did not, and the answer was on a form somebody signed. The honest answer, even where it costs you a better premium, is the only sensible one.

What they actually price on

Multi-factor authentication on email, remote access and privileged accounts. Backups that an attacker who owns your network cannot also encrypt, which usually means immutable or offline copies. Endpoint detection that somebody watches. A written incident response plan that has been exercised rather than filed. Patching, particularly on anything internet-facing.

The gap between "we have backups" and "we have backups an attacker cannot reach" is where most ransomware losses actually happen, and it is the question insurers have got much sharper about.

The tested plan is the cheap one

Of everything on that list, the incident response plan is the least expensive to fix and the one most often left undone. A tabletop exercise takes half a day, produces a written record, and answers the question honestly at renewal. It also tends to surface the gaps in the other controls, because running a scenario is how you discover that nobody knows who declares an incident.

Use the renewal date as the deadline

Insurance renewals are one of the few genuinely fixed deadlines in security. Work backwards from it. If MFA coverage is partial, close it before you answer rather than after. The premium difference is usually smaller than the cost of an uninsured incident, but the honesty is the point either way.

Our Cyber Insurance Readiness engagement works the application backwards into a fix list, and the Incident Response Tabletop covers the exercise itself, which is usually the fastest answer to change from a no to a yes.

'; $posts_content['investor-diligence-asking-about-security'] = '

Direct answer: Diligence is not looking for a perfect security programme. It is looking for evidence that you know what your risks are and that nothing in the stack will surprise the investor after the money goes in. Unknown risk is what costs you terms. Known and documented risk usually does not.

What actually gets examined

Who has access to production and how that is controlled. Whether customer data is handled in a way that matches what your contracts promise. Whether you have had an incident and how it was handled. What your compliance obligations are in the markets you sell into. Whether there is key-person risk in the infrastructure, which is a polite way of asking whether one person could disappear and take the deployment knowledge with them.

On the compliance side they want to know whether a customer commitment you have already signed requires something you do not yet have. A contractual promise of SOC 2 by a date, with no programme running, is the kind of finding that changes terms.

The answers that cost you

"We have never really looked at that" is the expensive one. So is discovering an unreported incident during diligence rather than before it. So is a security claim on your website that the technical reviewer can disprove in an afternoon, because it makes them doubt everything else in the data room.

A known gap with an owner and a date is a normal finding. Investors expect early companies to have gaps. What they are testing is whether management knows where they are.

What to have ready before the room opens

An access list for production. Your policy set, however short. A current risk register with real entries rather than placeholders. Any test or audit reports, with remediation status. A one-page summary of which frameworks your customers require and where you stand against them. If you have had an incident, a short written account of what happened and what changed afterwards.

Assembling that under time pressure while also running a raise is where the real cost sits. It is a week of work done calmly and a fortnight of chaos done late.

Security as a raise asset

Handled well this cuts both ways. A company that walks into diligence with a documented programme, a current test and a clear compliance position spends less time defending and more time selling the business. That is a valuation argument, not a compliance one.

We do this as Security Leadership for Fundraising, and if the round is closer than the readiness, the Fractional CISO engagement puts someone senior in the diligence calls with you.

'; $posts_content['failed-a-customer-security-review'] = '

Direct answer: Ask for the specific findings in writing, fix the ones that are blocking rather than all of them, and go back with evidence inside two weeks. Most failed reviews are recoverable, because the reviewer usually wanted to approve you and could not justify it on what they were given.

Find out what actually failed

"Did not meet our security requirements" is not a finding, it is a summary. Ask your champion for the specific items. Reviewers will normally share them, because a vendor that closes gaps is less work than running a new procurement.

When the list comes back, separate the blocking items from the nice-to-haves. A missing SOC 2 report is usually blocking. A missing formal asset inventory usually is not, if you can show the underlying control works.

Fix the blockers, not everything

The instinct after a rejection is to overhaul the whole programme. That takes months and the deal will not wait. Work only the items that stopped the approval, get evidence for each, and leave the rest for the programme you build afterwards.

Sometimes the blocker is not a control at all. It is that you answered inconsistently across the questionnaire, or claimed something you could not evidence. That is fixed with a corrected, documented response rather than engineering work.

Going back

Send a short written response that lists each finding, what changed, and the evidence attached. Do not re-argue the original answers. Reviewers respond well to a vendor who took the list seriously and came back quickly, because it tells them what you will be like as a supplier.

Speed matters more than completeness here. A response in two weeks with four of six items closed and dates on the rest lands better than a perfect response in three months, by which point the budget has usually moved.

The part that matters after the deal

A failed review is a preview. The next enterprise buyer will run the same process, and probably a stricter one. Fixing the blockers reopens this deal; building the programme is what stops the next review going the same way.

Enterprise Security Review Support is built for exactly this moment, and if the recurring blocker is that you have no report to hand over, SOC 2 in 75 Days is the usual answer.

'; $posts_content['procurement-wants-iso-27001-certificate'] = '

Direct answer: Ask whether they will accept SOC 2 or a documented readiness position instead. Many procurement teams write ISO 27001 into requirements as shorthand for "prove your security is managed", and will accept an equivalent. Some genuinely cannot, particularly in Europe and in regulated supply chains. The answer changes what you should do next, so ask before you commit to a certification.

Find out whether it is a hard requirement

There are three versions of this request. A hard contractual requirement, usually flowed down from the buyer\'s own certification or a regulator. A scoring criterion, where having it wins points but not having it is survivable. And a copy-paste from a template, where nobody has thought about it.

The third is more common than you would expect, and one email to your champion usually resolves it. If the requirement is scored rather than mandatory, a credible readiness position plus a certification date often carries enough weight.

If they will accept SOC 2

Take it, if you are selling mainly into North America. SOC 2 is generally faster to a first usable report, and it is what your other buyers will ask for anyway. The two frameworks share most of their underlying controls, so the work is not wasted if you certify later.

If it really is ISO 27001

Then plan for roughly four to six months to be ready for a Stage 1 audit, plus the certification body\'s own timeline. You cannot compress this the way you can compress a SOC 2 Type I, because certification requires a management system that has been operating, including an internal audit and a management review.

What you can do is give procurement something real in the meantime: a defined scope, a Statement of Applicability, a risk treatment plan and a booked audit date with a named certification body. That is a materially different conversation from "we are looking into it".

What not to do

Do not claim to be "ISO 27001 compliant" or "aligned". Procurement teams have seen it, it means nothing formally, and it reads as an attempt to blur a yes or no question. Either you hold a certificate from an accredited body or you do not, and being straight about which is the stronger position.

Our ISO 27001 Readiness engagement covers the management system through to Stage 2, and SOC 2 or ISO 27001 for Canadian startups works through which one your buyers will actually accept.

'; $posts_content['what-is-a-soc-2-bridge-letter'] = '

Direct answer: A bridge letter, sometimes called a gap letter, is a short statement from your management covering the period between the end of your SOC 2 report and the date a customer is asking. It says that nothing material changed in your controls during that gap. You write it, not your auditor, and it is not an audited document.

Why the gap exists

A SOC 2 Type II report covers a defined observation window, say January to December. Your customer is reading it in March. They need something covering January to March, and the auditor will not have looked at that period yet. The bridge letter fills it.

What it can and cannot say

It can state the report period, the gap period, and that management is not aware of any material changes to the control environment or of any control failures during the gap. It can note changes that did occur, which is the part people leave out and should not.

It cannot provide assurance. No independent party has tested anything in the gap period, and any letter implying otherwise is misleading. Sophisticated reviewers know this and treat the letter as a statement of management intent, which is what it is.

Who signs it

Somebody who can actually speak for the control environment, usually the CTO, CISO or CEO. It is signed and dated on company letterhead. Auditors do not issue bridge letters, and a firm offering to write one on your behalf is not doing you a favour.

When it stops being enough

Bridge letters cover a few months. Once the gap runs past roughly three months, reviewers start pushing back, and past six months many will not accept one at all. If you find yourself writing long bridge letters, the underlying issue is that your observation window has drifted out of step with your sales cycle.

If material changes did happen in the gap, say so plainly and describe the change. A letter that says nothing changed, followed by a customer discovering a migration or a breach, is significantly worse than no letter.

If you are working out how your report period should line up with your renewals, that is part of what we scope in compliance readiness.

'; $posts_content['statement-of-applicability-example'] = '

Direct answer: The Statement of Applicability, usually shortened to SoA, lists all 93 Annex A controls of ISO 27001:2022 and records for each one whether it applies to you, why, and whether it is currently implemented. It is mandatory, it is the document a Stage 1 auditor reads first, and it is where most first-time certifications come unstuck.

What it has to contain

For every one of the 93 controls: whether it is applicable, the justification for that decision, whether it is implemented, and a reference to how. The justification is the part that carries the weight. "Applicable, we process customer personal data" is a justification. "Yes" is not.

The SoA also has to line up with your risk assessment. If your risk treatment plan says you are mitigating a risk with a control, and the SoA marks that control as not applicable, the auditor has found a contradiction between two mandatory documents on their first read.

An example row

For control A.8.7, protection against malware: Applicable. Justification: corporate endpoints and production servers process customer data and are exposed to email and internet traffic. Implemented: yes. Reference: Endpoint Security Policy section 4, managed EDR deployed to all endpoints, monthly coverage report.

That single row tells an auditor what you decided, why, and where to go looking for evidence. Ninety-three rows of that standard is a SoA that survives Stage 1.

Excluding a control properly

You are allowed to exclude controls. You are not allowed to exclude them because they are inconvenient. A legitimate exclusion is a control that genuinely does not apply to your scope, and the justification has to hold up: A.7.4, physical security monitoring, can reasonably be excluded by a fully remote company with no offices and cloud-hosted infrastructure, and that justification should say exactly that.

What fails is excluding development security controls because you outsource development, or excluding supplier controls because you only use large vendors. Both are still your risk.

The mistakes that cost a Stage 1

Copying a SoA from a template and leaving justifications that describe somebody else\'s company. Marking controls implemented when the policy exists but nothing operates. Letting the SoA drift out of date after the risk assessment changes. Treating it as a spreadsheet to fill in at the end rather than the output of the risk work.

Built properly it is the most useful document in the whole management system, because it is the single place that connects your risks, your controls and your evidence. Built badly it is the fastest way to fail a Stage 1.

The SoA is a core deliverable of our ISO 27001 Readiness engagement, and the free ISO 27001 gap assessment will show you where you stand against the 93 controls before you commit to anything.

'; $posts_content['soc-2-exceptions-what-they-mean'] = '

Direct answer: An exception means the auditor tested a control and found an instance where it did not operate as described. It is not a failed audit, and most reports with a handful of exceptions are still perfectly sellable. What matters to a buyer is which control, how many instances, and what you did about it.

Exception, qualified opinion, adverse opinion

These get conflated constantly. An exception is a specific finding inside the report. The opinion is the auditor\'s overall conclusion. You can have several exceptions and still receive an unqualified opinion, which is the clean one.

A qualified opinion means the auditor concluded that one or more controls were not effective across the period. An adverse opinion, which is rare, means the control environment as a whole did not achieve the criteria. The distinction matters enormously when a buyer\'s reviewer opens the report, and founders often report the wrong one because they have not been told the difference.

How buyers actually read them

Reviewers look at where the exception sits. An exception in access management or change control gets attention, because those are the controls that stop the incidents they care about. An exception in a peripheral administrative control usually does not.

They also look at your management response, which is printed in the report alongside the finding. A response that names the cause, the fix and the date reads as a company that runs its controls. A defensive response, or none, reads as a company that will do this again.

What causes most exceptions

Almost never a missing control. Usually a control that exists but was not performed on schedule, or was performed and not evidenced. Access reviews done in month four and month eleven instead of quarterly. Onboarding checklists completed for nine of eleven new starters. Change approvals that happened in conversation and not in the ticket.

That is why the second report is usually cleaner than the first: the controls did not change, the discipline around evidencing them did.

What to do now

Fix the cause rather than the instance. If access reviews slipped because nobody owned the calendar, assign it and automate the reminder. Then make sure the next observation period contains a complete, dated record for every control that produced a finding.

Do not hide the report. Buyers who ask for SOC 2 are used to seeing exceptions, and a vendor who explains theirs clearly usually comes out ahead of one who stalls on sharing it.

If exceptions came from evidence discipline rather than from the controls themselves, that is exactly what SOC 2 Evidence Collection is for, and our free Workspace keeps the evidence register in one place between audits.

'; $posts_content['maintaining-soc-2-year-two'] = '

Direct answer: Year two is usually cheaper and harder. Cheaper because the controls, policies and scope already exist. Harder because nobody is running a project any more, and the controls now have to operate for twelve unbroken months while everyone is busy with something else.

What gets easier

Scope is settled. Policies exist and need reviewing rather than writing. Your auditor knows the environment, which shortens fieldwork. The system description needs updating, not drafting. Most companies see readiness effort drop substantially in the second cycle.

What gets harder

In year one somebody owned compliance full time, at least informally. In year two that person is back on their real job and the quarterly access review has no calendar entry. This is where almost every second-year exception comes from: the control still exists, nobody performed it on schedule, and there is no record.

The second failure is drift. You migrated a database, added a subprocessor, moved to a new identity provider, hired in a new country. Each is a normal business change and each one silently invalidates something in the system description or the vendor list.

The four things to put on a calendar

Quarterly access reviews with a named owner and a stored artefact. An annual policy review with a date and a signature. Vendor reassessment for anything material. A risk assessment refresh. If those four are scheduled with an owner rather than remembered, most of year two takes care of itself.

Watch the observation window

Type II reports cover a period, and buyers want a current one. If your window ends in December and your biggest renewal is in April, you will be writing bridge letters every year. Moving the window is easiest between cycles, and worth doing once rather than papering over annually.

What to tell your auditor early

Material changes, before fieldwork rather than during it. A new production region, a new subprocessor handling customer data, a change of identity provider. Auditors handle these routinely when told in advance and treat them as findings when discovered late.

Year two is where a compliance programme either becomes part of how the company runs or quietly decays into an annual scramble. If yours is drifting toward the second, that is what our compliance readiness engagements pick up, and the free Workspace keeps the evidence register live between audits rather than rebuilt each year.

'; $posts_content['soc-2-renewal-process'] = '

Direct answer: Start roughly three months before your current observation window closes. Renewal is not a new audit, it is the next observation period, and the main risk is a gap in coverage between one report ending and the next being issued.

The timeline

Three months out, confirm scope with your auditor and flag any material change. One month out, run an internal check that every control has a complete evidence record for the period. Window closes. Fieldwork runs for a few weeks. The report is issued some weeks after that.

That last stretch is the gap. Your previous report has expired in the eyes of a strict reviewer and the new one has not landed. This is exactly what a bridge letter covers, and knowing the dates in advance means you can send one before a customer asks.

What your auditor will want

An updated system description reflecting any change to infrastructure, subprocessors or scope. Evidence covering the full period rather than a snapshot. Remediation status for any prior-period exception. Updated policies with review dates inside the window.

Where renewals slip

Evidence gaps in months three to eight. Nobody notices at the time because nobody is looking, and it cannot be recreated afterwards. If your access reviews were quarterly and you have three of four, that is an exception you cannot fix retroactively.

The other one is scope creep. A product launched during the period that handles customer data is either in scope, in which case its controls needed to operate all year, or explicitly out, in which case the system description has to say so.

Changing auditors at renewal

Possible and sometimes sensible, but it adds time. A new firm has to understand the environment and will usually want more evidence in the first cycle. If you are moving because of price, get the readiness position clean first, because a well-prepared client is cheaper to audit and that is where the quote actually moves.

We coordinate renewals as part of auditor management, including running the internal check before the window closes rather than after.

'; $posts_content['continuous-compliance-monitoring'] = '

Direct answer: Continuous compliance monitoring means automated checks against your cloud and identity systems that flag drift as it happens rather than at audit time. It genuinely helps with technical configuration controls. It does nothing for the controls that involve a human doing something on a schedule, which is where most audit exceptions actually come from.

What it does well

Cloud configuration is where automation earns its keep. Storage that became public, encryption switched off, an over-permissive role, an account without MFA, a server missing patches. These are machine-checkable, they drift constantly, and a tool watching them daily beats a human checking quarterly.

What it cannot do

It cannot run your quarterly access review, because that is a judgement call about whether people should still have access. It cannot conduct your risk assessment, write your policies, hold a management review, run vendor due diligence, or deliver security training. Those are the controls that produce most exceptions, and no dashboard performs them for you.

It also cannot decide your scope, and scope is the single most consequential decision in the whole programme.

The honest split

Think of your control set in two halves. Roughly a third are technical and continuously verifiable, and automation is a real win there. The rest are process controls performed by people on a cadence, and for those the tool is a reminder system at best.

The mistake is buying a platform, watching the dashboard go green, and concluding you are audit-ready. Green means the technical checks pass. An auditor will sample the human ones.

Do you need to buy one

If your infrastructure changes often and you have engineers who will act on alerts, yes, it pays for itself. If you are a small team on a stable stack, a quarterly manual review plus your cloud provider\'s own security tooling covers the same ground for nothing.

We are not a monitoring vendor and have no reason to sell you one. Our free Workspace handles the other half, the evidence register and the scheduled human controls, and our comparison of compliance automation software is honest about when the paid tools are worth it.

'; $posts_content['cpcsc-annual-affirmation'] = '

Direct answer: Certification is assessed on a multi-year cycle, with an affirmation in between confirming that your controls are still in place and still operating. It is signed by someone able to speak for the organisation, and letting it lapse puts your eligibility for contracts at risk without any assessor visiting.

What you are affirming

That the requirements assessed at certification remain implemented, that your System Security Plan still describes the environment accurately, and that anything outstanding on your Plan of Action and Milestones is being worked. It is a statement about the present, not a repeat of the assessment.

Why it catches people out

The certificate arrives, the project team disbands, and eighteen months later the environment has moved. New systems inside the boundary. A subcontractor added. Staff who understood the controls have left. The affirmation asks you to confirm something is true, and confirming it without checking is the risk.

What to do before signing

Re-walk the boundary and confirm nothing new sits inside it undocumented. Check that the requirements with the highest turnover, mainly access control, configuration management and logging, still operate. Update the System Security Plan for any change. Refresh the Plan of Action and Milestones so the dates on it are real rather than historical.

Flow-down does not pause

If you subcontract any part of work that touches the protected information, their obligations run continuously too. A subcontractor who quietly stopped meeting a requirement is your exposure, not theirs, and the affirmation covers the whole scope you certified.

We run affirmation checks as part of CPCSC readiness, and the free CPCSC and CMMC self-assessment will show you where the boundary has moved before you sign anything.

'; $posts_content['soc-2-access-review-process'] = '

Direct answer: An access review that passes has four things: a complete list of who had access to what, a named reviewer who was qualified to judge it, a dated record of decisions including removals, and evidence the removals actually happened. Missing the last one is the most common exception in SOC 2.

Why this control fails so often

It is quarterly, it is nobody\'s favourite task, and it produces no visible benefit when it goes well. It is also the control auditors sample hardest, because inappropriate access is the root of a large share of real incidents.

The list has to be complete

Reviewing your identity provider is not reviewing your access. Cover production infrastructure, the identity provider itself, source control, the customer database, any admin console handling customer data, and anything with a standing key or service account.

Service accounts are the usual gap. They do not leave the company, nobody owns them, and they accumulate permissions. An auditor who asks "who owns this key and when was it last rotated" will find them.

The reviewer has to be able to judge

Somebody who knows whether a given engineer should still have production access. In practice that is an engineering lead per system, not one person signing for everything. A review signed by someone who could not possibly know is a documentation exercise, and it reads that way.

The record is the deliverable

Date, systems covered, who reviewed, the full list as it stood, decisions taken, and evidence of action. "Reviewed, no changes" for four consecutive quarters in a company that hired and lost people will attract questions.

Keep the artefact immutable. A spreadsheet that gets overwritten each quarter cannot prove what was reviewed in March.

A process small teams can keep up

Put the four dates in the calendar for the year with a named owner. Export access lists to a dated file. Have each system owner mark keep or remove. Action removals within a week and screenshot the result. Store everything together against the control. Ninety minutes a quarter, done properly, and it is the single highest-return habit in the whole programme.

Our free Workspace holds the schedule and the evidence against the control it satisfies, and SOC 2 Evidence Collection is where we run it with you when a period is already half gone.

'; $posts_content['soc-2-system-description-example'] = '

Direct answer: The system description is management\'s written account of the system being audited, and it forms part of the final report. You write it, your auditor reviews it, and it defines the boundary everything else is tested against. Get it wrong and you either pay to audit things you did not need to, or discover mid-period that something in production was never covered.

What it has to cover

The services you provide and to whom. The infrastructure, software, people, procedures and data that make up the system. The boundary, stated clearly enough that a reader knows what is excluded. Your subservice organisations and how you treat them. The controls that meet the criteria. Any relevant changes during the period.

An example structure

Section 1, overview: what the company does and which product the report covers. Section 2, boundary: the production environment, named regions, named data stores, plus what is explicitly out, such as the corporate website and internal analytics. Section 3, components: infrastructure, applications, the people involved by role, the data handled and its classification. Section 4, subservice organisations: your cloud provider and any processor, with whether you use the carve-out or inclusive method. Section 5, controls: mapped to the criteria. Section 6, changes in the period.

The boundary mistakes

Drawing it too wide is the expensive one. Including the corporate network, every internal tool and the marketing site means auditing all of it. Drawing it too narrow is the dangerous one: if the boundary excludes something customer data actually flows through, a sharp reviewer will notice the report does not cover what they are buying.

The third is leaving it static. Boundaries move when you add a region, a data store or a product, and the description has to move with them.

Carve-out versus inclusive

Almost every startup uses carve-out for its cloud provider: you state that the subservice organisation\'s controls are excluded and describe the complementary controls you assume they operate. Inclusive means your auditor tests their controls too, which is rarely practical for a hyperscaler and occasionally right for a small critical processor.

Write it before fieldwork

Teams that write it at the end are describing what happened rather than defining what was tested, and it shows. Draft it during scoping, agree it with your auditor, and treat it as the document everything else hangs off.

Scoping the boundary is the first thing we do in SOC 2 in 75 Days, because every other cost in the programme follows from it.

'; $posts_content['asset-inventory-for-soc-2'] = '

Direct answer: An asset inventory has to cover anything that stores, processes or transmits data in scope, with an owner and a classification for each. That includes cloud infrastructure, data stores, SaaS applications and endpoints. A list of laptop serial numbers satisfies neither framework.

What counts as an asset

Production infrastructure, including containers and serverless functions. Data stores, including the ones somebody spun up for analytics. SaaS applications holding company or customer data. Endpoints. Code repositories. Domains and certificates. Service accounts and API keys.

The SaaS list is where reality bites. Most companies discover during the first inventory that they are paying for tools nobody remembers buying, several holding customer data, none assessed as vendors.

The fields that matter

Identifier, type, owner, data classification, environment, and whether it sits inside the audit boundary. Owner and classification are the two auditors press on, because without them you cannot show that controls are applied proportionately.

Every asset needs a named person, not a team. "Platform" is not an owner. When an auditor asks who is accountable for a data store, a name is the answer.

Keeping it current

A manually maintained spreadsheet is accurate for about a fortnight. Pull cloud resources from your provider\'s inventory API, pull SaaS from your identity provider\'s application list, and reconcile quarterly. What you maintain by hand is the ownership and classification layer, which changes far more slowly than the resources.

Tie it to the access review. The same quarter you review who has access, confirm the inventory still matches reality. Two controls, one sitting.

Where it connects

The inventory drives risk assessment, access control, vendor management and incident response scoping. Every one of those depends on knowing what you have. Auditors treat a weak inventory as a signal about the whole programme, which is why it is worth doing early rather than in the last fortnight.

The free Workspace keeps the inventory beside the controls it supports, and our risk register builder is free if you want to start from the risk side instead.

'; $posts_content['risk-assessment-template-canadian-startup'] = '

Direct answer: You need a documented, repeatable method that identifies risks, scores them on likelihood and impact, records a treatment decision with an owner and a date, and gets reviewed at least annually. The method matters less than applying it consistently and being able to show you did.

The method

Identify what you are protecting, using your asset inventory. For each, ask what could realistically go wrong. Score likelihood and impact on a simple scale, and be honest rather than conservative. Decide treatment: mitigate, accept, transfer or avoid. Assign an owner and a date. Review on a schedule.

A five-by-five matrix is plenty. Elaborate quantitative models look impressive and are almost never maintained, and an unmaintained risk register is worse than a simple current one.

Risks worth listing for a Canadian SaaS

Credential compromise leading to production access. A subprocessor breach exposing customer data. Ransomware on corporate endpoints. A departing employee retaining access. Data residency obligations conflicting with where you actually host. Personal information handled beyond what your privacy notice says. Single points of failure in deployment knowledge. Where you ship AI features, model and prompt handling of customer data.

The Canadian layer

PIPEDA applies federally to commercial personal information. Quebec\'s Law 25 adds its own obligations if you have customers there, including a named privacy officer and breach reporting. Ontario health data brings PHIPA into scope. These belong in the register as compliance risks with owners, because a buyer\'s reviewer will ask and "we are not sure" is a finding.

Scoring that survives an audit

Auditors do not grade your numbers. They check that the method is documented, applied consistently, and that treatment decisions were actually acted on. A high risk accepted with a written rationale and a sign-off is perfectly acceptable. A high risk with a treatment date eighteen months in the past is not.

Keep it alive

Review quarterly at the same sitting as the access review, and refresh properly once a year. Add a risk whenever you add a subprocessor, a region or a product line. A register that only changes at audit time is visibly a compliance artefact rather than a management tool.

Our risk register builder is free and starts you with the entries above, and the Workspace keeps treatment dates in front of you instead of in a spreadsheet nobody opens.

'; $posts_content['hidden-costs-of-soc-2'] = '

Direct answer: The two numbers you get quoted, readiness and the audit fee, are usually a bit over half the real cost. The rest is engineering time on remediation, a penetration test, any tooling you buy, and the internal hours spent collecting evidence. Budget for all five or the project stalls in month three.

The five real line items

Readiness. Gap analysis, policies, control build-out, evidence and audit coordination. Ours starts at $3,000 for the gap analysis, with remediation scoped after it, and the figures are on the pricing page.

The audit itself. Paid to an independent CPA firm, never to us, because the same firm cannot do both. This is a separate invoice and a separate relationship.

Engineering time. The one nobody budgets. Fixing what the gap analysis finds is real work: logging, access changes, an identity provider migration, encryption gaps. On a small team that is often several weeks of an engineer, and it lands on top of the roadmap.

A penetration test. Not formally mandatory, and expected in practice by auditors and buyers alike. From $1,000 depending on scope.

Evidence collection. Somebody has to gather screenshots, exports and tickets across the observation period. Done weekly it is minor. Left to the end it is a fortnight of somebody\'s life and it produces gaps that cannot be backfilled.

The costs that only appear later

The observation period itself, if you want Type II, which means controls operating for months before you have a report to sell with. Renewal every year. A compliance platform subscription, if you buy one, which is annual and rarely cancelled. And the opportunity cost of whoever ends up owning this internally.

Where money gets wasted

Scoping too wide is the biggest. Every extra system in the boundary is more controls, more evidence and more audit hours. Buying tooling before you know your gaps is second: teams purchase a platform, then discover the work it automates was not their problem.

Third is arriving at the auditor unprepared. A disorganised client costs more to audit because it takes longer, and firms price that in. Arriving with a clean evidence package is worth real money. We took $11,000 off one client\'s quote that way, which is on our case studies.

A realistic total

For a small Canadian SaaS with a straightforward cloud stack, the honest answer is that readiness plus audit plus a pen test is the visible spend, and you should assume meaningful engineering time on top. Anyone quoting a single all-in number without seeing your environment is guessing at the part that varies most.

If you want the number for your situation rather than a range, tell us the shape of the environment and we will scope it.

'; $posts_content['cheapest-way-to-get-soc-2'] = '

Direct answer: Do the gap analysis and policy work yourself, keep the scope as narrow as honestly possible, start with a Type I, and pay only for the audit and anything requiring independence. That is the genuinely cheap route. The audit fee itself cannot be avoided, because a SOC 2 report has to be issued by an independent CPA firm.

What you can do yourself

Scoping, if you are disciplined about it. Policy writing, using a decent starting point and editing it to match what you actually do. Evidence collection, which is administration rather than expertise. Most remediation, since your engineers know your systems better than any consultant will.

Our free SOC 2 readiness tool and the free Workspace cover the gap analysis and the evidence register at no cost, deliberately.

What you cannot avoid paying for

The audit. A SOC 2 report is an attestation from a licensed CPA firm and there is no self-certified version. Anyone offering you a SOC 2 certificate directly is selling something that is not a SOC 2 report.

The three levers that actually move cost

Scope. The single biggest. One product, one environment, the minimum trust services criteria your buyers require. Most companies need Security only; adding Availability or Confidentiality because they sound thorough adds controls and audit hours for no commercial return.

Type I first. A point-in-time report, faster and cheaper, and usually enough to unblock a deal. Run the Type II window afterwards.

Preparation. Auditors price on effort. Arriving organised is the cheapest discount available.

The false economies

Buying a compliance platform before you know your gaps. Choosing the cheapest auditor without checking whether your buyers accept them. Doing everything internally when the person doing it is your only senior engineer, which trades cash for roadmap. And writing policies you do not follow, which converts a cheap project into exceptions on the report.

Where paying is cheaper

When a deal is waiting. If SOC 2 is blocking revenue, weeks matter more than the fee, and the DIY route is reliably slower. The arithmetic is the deal value against the difference in fees, and it is usually not close.

If you want to try it yourself first, everything free we have is on the tools page. If the clock is the problem instead, SOC 2 in 75 Days exists for exactly that.

'; $posts_content['vciso-cost-per-month'] = '

Direct answer: A fractional or virtual CISO in Canada typically runs from around $3,000 a month for a light advisory engagement up into five figures for heavy involvement during an audit or a funding round. Ours starts at $3,000 a month and the figure is published on the pricing page.

What changes the number

Hours, mostly, but the shape matters more than the total. A vCISO who attends a monthly steering call and answers questionnaires is a different engagement from one running an active SOC 2 programme, sitting in customer security calls and reporting to your board.

Regulatory context moves it too. A fintech dealing with OSFI expectations, or a defence supplier under CPCSC, needs more senior time than a SaaS with one enterprise buyer asking for SOC 2.

Compared with hiring

A full-time security leader in Toronto costs well into six figures once you include benefits and equity, plus the months to hire and the risk of getting it wrong. The fractional version buys the judgement without the fixed cost, which is the whole point at your stage.

The honest counter is that a fractional CISO is not there every day. If security is genuinely core to your product rather than a requirement of selling it, you will eventually want somebody in-house, and a good vCISO will tell you when that point arrives and help you hire.

When you need something smaller

If the actual problem is one questionnaire, buy help with the questionnaire. If it is one audit, buy readiness. A retainer is for ongoing accountability: somebody who owns the programme, answers for it to buyers and your board, and is still there next quarter.

Our free vCISO ROI calculator compares the two against your own numbers, and the full-time CISO comparison lays out where each option stops making sense.

'; $posts_content['is-chatgpt-safe-for-company-data'] = '

Direct answer: The business and enterprise tiers of the major AI providers contractually exclude your inputs from model training and are defensible for most company data. The free consumer tiers are not, and neither is any of it for customer personal information unless you have checked your own contracts and privacy notice first. The bigger risk is that you have no policy and no idea who is using what.

The tier distinction matters more than the vendor

Paid business tiers generally offer data processing terms, no training on your inputs, retention controls and administrative visibility. Consumer tiers historically train on inputs by default. Same brand, materially different obligations, and staff cannot be expected to know which one they signed into.

What your own contracts say

This is where it usually breaks. Your customer agreements probably name your subprocessors and commit you to notifying changes. If an employee pastes customer data into a tool that is not on that list, you may have breached a contract regardless of how safe the tool is. Under PIPEDA and Quebec\'s Law 25 there are transfer and accountability obligations on top.

So the question is not really "is it safe". It is "is it a disclosed subprocessor, and does our privacy notice cover it".

What auditors and buyers now ask

Whether you have an acceptable use policy for AI. Which tools are approved. How you prevent customer data reaching unapproved ones. Whether staff have been told. Whether AI vendors go through the same vendor risk process as any other processor. A shrug is a finding, and it is showing up in enterprise questionnaires routinely now.

Shadow AI is the real exposure

The tool your policy covers is rarely the problem. It is the browser extension, the personal account, the AI feature quietly switched on inside a SaaS product you already use. Most companies underestimate their usage by a wide margin because they only count what they pay for.

A position that survives review

Approve a small number of business-tier tools. Write a short acceptable use policy saying what may and may not be pasted, with customer personal information as a clear no unless the tool is a disclosed subprocessor. Put AI vendors through vendor risk. Tell people, once, in plain language. Then check what is actually being used rather than assuming.

Our free AI acceptable use policy generator produces the policy, the shadow AI risk checker finds the usage you do not know about, and the Shadow AI Audit is the engagement version when the answer needs to hold up in front of a buyer.

'; $posts_content['securing-rag-pipelines'] = '

Direct answer: The dominant RAG failure is not the model, it is retrieval returning documents the user was never entitled to see. If your vector store does not carry the same access control as the source system, the model will faithfully summarise data the user could not otherwise open, and it will do it convincingly.

Permissions do not survive embedding

Documents usually arrive from systems with real access control: a wiki, a ticketing system, a shared drive. Embedding strips that. Unless you carry permissions into the index and filter at query time against the requesting user, retrieval treats every chunk as equally available.

This is the finding we see most often, and it is rarely deliberate. It happens because the ingestion pipeline was built by someone thinking about relevance, not entitlement.

Indirect prompt injection

If your pipeline ingests anything users can influence, such as support tickets, uploaded files or crawled pages, an attacker can plant instructions inside a document. The model retrieves it as context and follows it. That is how retrieval turns into data exfiltration or tool abuse without anyone attacking your API directly.

Treat retrieved content as untrusted input. It is the same lesson as user input in a web application, relearned in a new place.

The other leaks

Chunks that cross tenant boundaries in a multi-tenant index. Embeddings retained after the source document was deleted, which quietly breaks a deletion request. Debug logs capturing full prompts including retrieved customer data. Overly broad tool permissions on an agent that can act as well as answer.

What to test before shipping

Ask whether a user in tenant A can retrieve anything from tenant B. Whether a low-privilege user can surface content from a restricted source. Whether a planted instruction in an ingested document changes behaviour. Whether deleting a source document removes it from retrieval. Whether prompts and retrieved context appear in logs.

What compliance will ask

If customer data flows through retrieval, your vector store is in scope. It needs classification, access control, retention and a place in your subprocessor list if it is hosted elsewhere. Buyers with mature security teams are now asking this directly, and the answer needs to be more specific than naming the model provider.

This is the core of our AI and LLM security assessment, delivered with our offensive-security partner, and LLM red teaming is the adversarial version when you want it attacked properly.

'; $posts_content['ai-governance-framework-for-startups'] = '

Direct answer: For a startup, AI governance is four things: an inventory of where you use AI, a decision on what data may reach it, a named owner, and a record of what you told customers. That is genuinely enough to answer most buyer questions and to satisfy the AI section of a security questionnaire. Formal ISO 42001 certification is a later decision.

Start with the inventory

Every AI feature in your product, every AI tool your team uses, and every AI capability inside SaaS you already buy. That third category is the one that surprises people, because vendors keep switching features on.

For each, record what data reaches it, whether it is a subprocessor, and who owns the decision. Most companies cannot answer these on the day they are asked, which is the actual failure.

Decide the data rule and write it down

One clear statement: what may and may not go into an AI system, with customer personal information handled explicitly. Then make it real by approving specific tools rather than issuing a prohibition everyone routes around.

What buyers are asking

Enterprise questionnaires now routinely ask whether AI is used to process their data, whether their data trains a model, whether a human reviews consequential outputs, and how you handle the risks specific to models. Those four are answerable in a paragraph each if you did the inventory, and unanswerable if you did not.

How much ISO 42001 to adopt

The standard is a management system for AI: context, policy, roles, risk assessment specific to AI, lifecycle controls, monitoring. You can adopt the shape without certifying, and that is what we usually recommend early. Certify when a customer or regulator requires it, not before.

If you sell into the EU, the AI Act has its own timeline and classification, which is a separate question from ISO 42001 and worth answering early because the obligation depends on what your system does rather than where you are.

The overlap you already have

If you are doing SOC 2 or ISO 27001, much of the underlying control set carries over: access control, vendor management, change control, incident response. AI governance mostly adds model-specific risk and transparency. Building it beside an existing programme is far cheaper than treating it as a separate project.

Our free AI governance assessment scores you against the shape of ISO 42001, the EU AI Act classifier tells you which obligations apply, and the AI Governance Program is the engagement when a buyer needs a real answer.

'; $posts_content['phipa-compliance-ontario'] = '

Direct answer: PHIPA is Ontario\'s health privacy law and it applies to personal health information handled by health information custodians and their agents. If you build software for Ontario clinics, hospitals or practitioners, you are almost certainly an agent, and your obligations flow from the custodian\'s through your contract with them.

Custodian or agent

A custodian is the clinic, hospital or practitioner who holds the health information. An agent acts on the custodian\'s behalf, which is where most health tech vendors sit. Agents may only use health information as permitted by the custodian, for the purposes the custodian permits, and must not use it for their own purposes without authority.

That is stricter than founders expect, and it catches product analytics. Using identifiable health information to improve your product is not automatically permitted because it sits in your database.

What the custodian will require of you

A written agreement covering permitted use. Safeguards proportionate to the sensitivity, which for health data means encryption, access control and logging that shows who accessed which record. Breach notification to the custodian, who has their own duty to notify the Information and Privacy Commissioner of Ontario and affected individuals. Retention and secure disposal. Often a privacy impact assessment before deployment.

PHIPA is not HIPAA

They are different statutes in different countries. A HIPAA-oriented programme covers much of the same practical ground, so the safeguards travel, but the legal obligations, the regulator and the breach thresholds do not. Claiming HIPAA compliance to an Ontario custodian answers a question nobody asked.

If you sell into both, run one control set and map it to both obligations rather than running two programmes.

Where SOC 2 fits

PHIPA is law; SOC 2 is an attestation. Neither replaces the other. In practice Ontario custodians increasingly ask for a SOC 2 report as evidence that the safeguards PHIPA requires actually operate, so the efficient route is a SOC 2 scoped to include the controls your PHIPA obligations turn on.

Our health data readiness work covers both, and this case study walks through a SOC 2 Type I for an Ontario medtech company putting an AI clinical assistant in front of practitioners.

'; $posts_content['osfi-b-13-requirements'] = '

Direct answer: OSFI Guideline B-13 sets technology and cyber risk expectations for federally regulated financial institutions. It does not apply to you directly as a vendor, but your bank or insurer customer has to demonstrate they manage third-party technology risk, so it arrives as contract terms, questionnaires and audit rights.

What the guideline covers

Governance and accountability for technology risk. Technology operations and resilience, including change and incident management. Cyber security, covering identity, protection, detection, response and recovery. Third-party technology risk, which is the part that reaches you.

How it lands on a vendor

Expect a deeper due diligence process than a normal enterprise sale. Contractual security obligations with specific control requirements. Incident notification within tight windows, often much shorter than your standard terms. Audit or assessment rights. Business continuity and exit provisions, because the institution has to show it could move off you.

Concentration risk comes up too: if you host everything in one region with one provider, expect questions about what happens when it fails.

B-13, B-10 and E-21

They interlock. B-10 covers third-party risk management generally, which is the route most vendor obligations actually travel down. B-13 is technology and cyber specifically. E-21 covers operational resilience and risk management more broadly. A financial institution buying your product may cite any of the three, and the practical requirements overlap heavily.

What to have ready

A SOC 2 Type II report, which does most of the heavy lifting. A tested incident response plan with notification timelines you can actually meet. Business continuity and disaster recovery evidence, tested rather than documented. A subprocessor list with your own vendor assessments. Clear data residency answers.

The incident notification window is where deals stall. Institutions often want notification in hours. If your contract says thirty days and your plan has never been exercised, that gap surfaces in review.

Getting ahead of it

Fintech is the vertical where this comes up first and hardest, which is why we run a fintech practice. If a bank deal is in front of you now, Enterprise Security Review Support is built for the review itself, and the tabletop is usually the fastest way to make the resilience answers real.

'; $posts_content['ransomware-first-24-hours'] = '

Direct answer: Isolate rather than shut down, preserve evidence, get legal and insurance involved before you negotiate anything, and start the notification clock deliberately. The most expensive mistakes in the first day are wiping machines to restore faster and telling customers something you have to correct later.

First hour

Isolate affected systems from the network. Do not power them off if you can avoid it, because memory holds evidence you will want. Disable the compromised accounts you know about. Get everyone communicating on a channel the attacker is not in, which usually means not your normal chat if identity was compromised.

Call your cyber insurer before doing anything else expensive. Policies frequently require you to use their approved responders, and engaging your own first can affect the claim.

What not to do

Do not rebuild immediately. Restoring over the evidence means you will never know how they got in, and you will restore the same weakness. Do not pay or open negotiation without legal advice, sanctions screening and insurer involvement. Do not tell customers "no data was accessed" before anyone has established that.

Establish scope before you communicate

The questions that matter: what was accessed as opposed to encrypted, whether personal information was involved, which customers are affected, and whether data was taken as well as locked. Modern ransomware usually exfiltrates first, so encryption without exfiltration is the exception rather than the assumption.

The Canadian notification clock

Under PIPEDA you must report breaches of security safeguards that create a real risk of significant harm to the Privacy Commissioner of Canada and notify affected individuals, as soon as feasible, and keep records of all breaches regardless. Quebec\'s Law 25 has its own obligations if you hold data on Quebec residents. Health information brings PHIPA and the Ontario Commissioner into it.

Your customer contracts almost certainly have their own notification windows, often far shorter than the statutory ones. Check them on day one, not week two.

After

A written post-incident review covering root cause, what worked and what did not, with owners and dates. You will need it for insurers, for customers, and for the security reviews that follow, because buyers will ask about the incident for years and a clear account of what changed is what closes the conversation.

If you are in this now and have no retainer, contact us and say it is live. If you are reading this beforehand, which is the better time, On-Call Incident Response puts the relationship and the SLA in place before you need them, and a tabletop is how you find out whether the plan works while it is still cheap to find out.

'; $posts_content['customer-asking-for-trust-center'] = '

Direct answer: A trust center is a public page that answers the security questions buyers keep asking, with the sensitive documents available on request. It exists to stop you answering the same questionnaire by hand every quarter, and a good one measurably shortens security review.

What goes on the public page

Which frameworks you hold or are working toward, with dates. Where data is hosted and in which regions. Encryption in transit and at rest. Your subprocessor list. How to report a vulnerability. How to reach a human about security. Your incident notification commitment.

None of that is sensitive. All of it is asked constantly, and publishing it removes the first round of most reviews.

What to gate

The SOC 2 report itself, behind a request form or an NDA. Penetration test reports, or better, the attestation letter. Your policy set. Anything with architectural detail. Gating is normal and buyers expect it, so long as the request is answered quickly.

What not to do

Do not claim frameworks you do not hold. "SOC 2 compliant" when you have no report is the single fastest way to lose a technical reviewer\'s trust, and they check. If you are in progress, say in progress with a target date.

Do not let it go stale. A trust page listing a subprocessor you dropped a year ago, or a report period that expired, is worse than no page, because it tells a reviewer nobody owns this.

Why it pays

The economics are straightforward. Every enterprise buyer asks broadly the same forty questions. Answering them once publicly means most reviews start further along, and the ones that still send a questionnaire can often be answered by pointing at the page. It also signals maturity in a way that costs nothing to maintain once built.

We build these as Trust Center Setup, ours is at traztech.ca/trust-center if you want to see the shape, and the free trust center builder will draft the content for you.

'; $posts_content['how-to-vet-a-penetration-testing-firm'] = '

Direct answer: Ask who is doing the testing and what they have published, whether a retest is included and for how long, whether findings map to the framework you are audited against, and to see a redacted sample report. A firm that cannot answer those four quickly is selling you scanner output.

Who actually does the work

Sales scoping and delivery are often different people, sometimes different companies. Ask who will run your test, what their background is, and whether the work is subcontracted. Published research, CVEs and recognised certifications are reasonable signals, and any firm proud of theirs will tell you immediately.

Is it a test or a scan

A scan is automated and finds known issues. A test is a person chaining findings and proving what an attacker could reach, including business logic that no scanner understands. Both have value and they cost very different amounts.

The tell is the report. Scanner output lists findings by CVSS with generic remediation. A real report describes attack paths, what the tester achieved, and what it means for your business.

The retest question

Remediation evidence is what an auditor samples. A test without a retest leaves you with a list of findings and no proof you closed them, which is worth much less at audit time. Ask whether retesting is included, how long the window is, and whether the updated report reflects closure.

Scope before price

A good scope names the applications, environments and IP ranges in and out of scope, the testing window, whether it is black, grey or white box, whether social engineering is included, rules of engagement, and escalation contacts if something breaks or they find something critical mid-test.

Beware a fixed price quoted without any of that. It means either the scope is trivially small or it will be revised upward once the work starts.

Does the report satisfy your buyer

If the test exists to unblock a deal or support an audit, check the report will do that job. It should be scoped to the system your buyer cares about, dated within the last year, and issued with an attestation letter you can share without handing over reproduction steps.

Ours is scoped that way deliberately, described on the compliance penetration testing page, with prices on the pricing page and the scoping calculator free if you want to size it before talking to anyone.

'; $posts_content['web3-blockchain-penetration-testing'] = '

Direct answer: A web3 penetration test covers the infrastructure around your contracts: key management, the bridge and oracle integrations, the APIs, the admin surfaces and the wallet handling. It is a different exercise from a smart contract audit, which reviews the contract code itself. Most real losses come from the first category, not the second.

Where the money actually goes

The headline exploits get described as smart contract hacks, but a large share of blockchain losses trace back to ordinary security failures: a compromised deployer key, an admin function with weak access control, a bridge validator set that could be outvoted, an oracle that could be manipulated, or an exchange employee phished into approving a withdrawal.

Those are penetration testing findings, not contract logic bugs. A contract can be formally verified and still sit behind an upgrade key held in one engineer\'s password manager.

What a web3 penetration test covers

Key and signer management. Where deployer, upgrade, treasury and validator keys live, who can use them, whether multisig thresholds are meaningful, and what happens when a signer leaves the company.

Admin and privileged functions. Pause, upgrade, mint, fee and parameter functions, and whether the access control on them survives contact with a determined attacker or a compromised account.

Bridges and oracles. The trust assumptions between chains and the price or data feeds contracts depend on. This is where the largest single incidents in the sector have come from.

The off-chain application. The API, the indexer, the front end, and the wallet connection flow. Signature phishing and transaction spoofing happen in the interface, not the chain.

Cloud and CI/CD. Deployment pipelines that can push contract changes, secrets in build systems, and the infrastructure the whole thing runs on.

How this differs from a smart contract audit

A smart contract audit is a line-by-line review of the contract code by specialists in Solidity, Move or whichever language you use, often with formal verification. If your risk is reentrancy, arithmetic or logic flaws in the contract itself, that is what you need and you should hire a firm that does only that.

We are not a smart contract audit shop and will say so. What we test is everything the contract touches and everything that can reach the contract, which is where compliance frameworks and enterprise buyers focus too. Most serious projects end up buying both, from different firms, and that separation is healthy.

Scoping by what you run

An exchange or custodian: key custody, withdrawal approval flows, internal admin tooling, and the insider threat model. Regulators and auditors will care about the same things.

A wallet: key generation and storage on device, the recovery flow, transaction signing and display, and the phishing resistance of what the user is shown before they approve.

A bridge: validator or relayer trust assumptions, message verification, replay protection, and the operational security of whoever holds the keys.

A DeFi protocol: oracle dependencies, admin key control, upgrade paths, and the front end that users actually interact with.

Where compliance comes in

If you are a crypto business selling to institutions, custodying assets, or dealing with a Canadian regulator, testing usually has to produce evidence as well as findings. Scope it so the report can be handed to an auditor or an institutional counterparty, and time it so it sits inside the period a SOC 2 covers.

We deliver testing with our offensive-security partner and scope it to double as evidence. See compliance penetration testing, penetration testing for crypto, and SOC 2 for crypto companies if the institutional side is what is driving this.

'; $posts_content['soc-2-for-crypto-wallets-and-lenders'] = '

Direct answer: The framework is the same, the scope is not. If you custody keys or assets, the audit boundary has to include key management, and auditors will press on segregation of duties, withdrawal approval and insider threat far harder than they would for ordinary SaaS. Most crypto businesses also need Availability and Confidentiality alongside Security, where a normal startup needs Security only.

Why institutional counterparties ask

A bank, an exchange, a fund or a corporate treasury cannot onboard you without a third-party assurance report. SOC 2 Type II is the one they recognise. For lending platforms it usually arrives with the first institutional lender; for wallets it arrives with the first enterprise or custody partner.

What changes for a wallet

Key generation, storage and recovery move to the centre of the audit. Expect questions on where private keys are generated, whether anyone can extract them, how hardware security modules or secure enclaves are used, what the recovery flow permits, and who could reconstruct a key by colluding with whom.

The last one matters most. Segregation of duties is a normal SOC 2 control that becomes existential when the thing being separated is control of customer assets. If one engineer can move funds alone, that will be a finding regardless of how strong the cryptography is.

What changes for a lending platform

Availability moves from optional to expected, because liquidation logic that stops running has direct financial consequences for customers. Auditors will look at monitoring, incident response and capacity in a way they would not for a marketing tool.

Confidentiality usually comes in too, given position and collateral data. And the interaction between your controls and any oracle or price feed you depend on becomes part of the conversation, because a dependency that fails is your availability problem.

Which criteria to pick

Security is mandatory in every SOC 2. For a wallet, add Confidentiality and consider Availability. For a lending platform, add Availability and Confidentiality. Processing Integrity comes up occasionally where you are executing transactions on a customer\'s behalf and someone wants assurance the execution is complete and accurate.

Each additional criterion adds controls, evidence and audit hours, so pick from what counterparties actually ask for rather than from what sounds thorough.

The boundary decision

Custody infrastructure has to be in scope. Beyond that the useful question is whether your on-chain components are in the boundary at all. Usually the contracts themselves sit outside it, with the systems that deploy, monitor and interact with them inside, and a penetration test covering the surrounding infrastructure referenced as evidence.

Getting this wrong in either direction is expensive, which is why it is the first thing we settle. See SOC 2 for crypto companies, what a web3 penetration test covers, and SOC 2 in 75 Days for what the programme costs.

'; $posts_content['how-to-assess-an-ai-vendor'] = '

Direct answer: Assess an AI vendor the way you assess any processor, then add four questions specific to models: does our data train anything, how long is it retained and where, which model providers sit behind you as subprocessors, and what happens when the model changes. Those four are where standard vendor questionnaires come up short.

Start with the normal assessment

An AI vendor is still a vendor. You want their security posture, a SOC 2 or ISO 27001 report if they have one, their subprocessor list, breach notification terms, data residency and deletion commitments. If they cannot produce any assurance report and they will handle customer data, that is the answer before you reach the AI questions.

The four AI-specific questions

Does our data train your models? Get it in the contract, not the marketing page. Business and enterprise tiers of the major providers exclude training by default; consumer tiers historically did not. The tier matters more than the brand.

What is retained, for how long, and where? Many providers retain inputs for abuse monitoring even when they do not train on them, often for 30 days, sometimes in a different jurisdiction from the one you contracted for. That retention is a disclosure you may owe your own customers.

Who is behind you? Most AI products are a wrapper over one or more foundation models. Those providers are your subprocessors in practice. Ask which ones, in which regions, and whether they can change without telling you.

What happens when the model changes? A model version can change behaviour without any change to the API. If you rely on the output for anything consequential, you want notice of material changes and a way to pin or test a version.

Match the depth to the exposure

A tool summarising public marketing copy is not the same risk as one processing customer support transcripts containing personal information, and neither is the same as an agent with write access to your systems. Assess in proportion. A single questionnaire applied uniformly wastes effort on the harmless and under-inspects the dangerous.

The practical test: could this vendor\'s failure expose customer data, break a contractual commitment, or take an action in our environment? Any yes moves it up a tier.

When they will not answer

Some AI vendors, particularly early ones, cannot answer these questions because nobody has asked before. That is not automatically disqualifying, but it changes what you should do: restrict what data reaches them, avoid personal information entirely, get the commitments you can into the contract, and set a review date.

A vendor that refuses to answer, as opposed to one that is still working it out, is a different matter.

What your own buyers will ask

Enterprise security reviews now routinely ask whether you use AI to process customer data, which providers, whether customer data trains a model, and how you assess AI vendors. Your answer to that last one is your process. Having one written down, applied and evidenced is the difference between answering in a paragraph and stalling a deal.

Our AI Vendor Risk Assessment runs this across your stack and produces the register buyers ask for, the shadow AI risk checker is free and finds the tools you did not know about, and whether staff can paste company data into AI tools covers the policy side.

'; $posts_content['agentic-ai-vendor-risk'] = '

Direct answer: When a vendor\'s AI can take actions in your systems rather than only return text, assess it as you would a privileged integration, not a SaaS tool. The controlling questions become what it is allowed to do, what stops it doing more, and what record exists afterwards. Data handling still matters; blast radius matters more.

Why the usual assessment falls short

A conventional vendor review asks where data goes and who can see it. An agent introduces a second question: what can it change. It holds credentials, calls tools, and decides which to call based on text it was given, some of which may come from outside your organisation.

That combination, non-deterministic decisions plus real permissions, is not something standard vendor questionnaires were written for.

The questions that matter

What permissions does it hold, and under whose identity? Its own service account or an impersonated user? Scoped to a workspace or granted broadly because that was easier to configure? This is the single most useful question and it is frequently answered with "admin, for now".

What can it do without a human? Draw the line explicitly. Reading is one tier. Writing is another. Sending external communications, moving money or changing access is a third that should generally require approval.

How is prompt injection handled? If the agent processes anything a third party can influence, a ticket, an email, an uploaded file, a web page, then instructions can be planted in that content. Ask what stops retrieved content being treated as instructions.

What is logged? You need a record of what the agent did, on whose behalf, and why, in a form you can hand to an auditor or use in an incident. Many agent products log the conversation but not the actions.

How do you stop it? A kill switch that revokes its credentials, and a known blast radius if it misbehaves for an hour before anyone notices.

Treat it as an identity

The cleanest mental model is that you are onboarding a very fast employee with unusual judgement. Give it the least privilege that lets it work. Put it in your access review. Give it an owner. Include it in offboarding when the vendor relationship ends, because a forgotten agent credential is a standing back door.

What auditors and buyers are starting to ask

Agents are appearing in enterprise security reviews now: whether AI systems can take actions in your environment, what approvals gate them, and how those actions are logged. If your access review covers humans only, an agent with production write access is a finding waiting to be written.

Our AI Vendor Risk Assessment covers agents as a distinct tier, and securing a RAG pipeline goes deeper on the injection route that turns retrieval into action.

'; $posts_content['ai-vendor-risk-management-program'] = '

Direct answer: Four parts: find every AI tool actually in use, tier them by what data and permissions they hold, assess proportionally to the tier, and re-review on a schedule. The hard part is discovery, because most AI adoption happens without procurement and most inventories are wrong on day one.

Discovery, and why your list is incomplete

Start from what you pay for, then widen. Expense reports catch corporate cards. Your identity provider\'s application list catches anything using SSO. Browser extensions and personal accounts catch nothing, which is why an anonymous amnesty question to the team usually surfaces more than any tool does.

Then add the category everyone forgets: AI features switched on inside software you already buy. Your CRM, support desk and note-taker all shipped AI capability recently, and none of it went through procurement because you already owned the product.

Tiering

Tier 1, high: processes customer personal information, or holds write access to your systems. Full assessment, contractual commitments, named owner, annual review.

Tier 2, medium: processes internal but non-personal data. Lighter assessment, subprocessor and training questions answered, reviewed on renewal.

Tier 3, low: public data only, no integration. Record it and move on.

Tiering is what makes the programme survivable. Assessing everything to Tier 1 depth means assessing nothing well, and the first time it feels like theatre is the last time anyone updates it.

The assessment

Reuse your existing vendor process and add the AI questions: training on inputs, retention and location, model providers as subprocessors, and change notification. For anything agentic, add permissions, approval gates and logging. Record answers with a date and a source, so that when a buyer asks you can show the evidence rather than the conclusion.

The cadence

Quarterly discovery, because adoption moves faster than procurement. Annual reassessment for Tier 1. Reassess on trigger for everything: a new integration, a permission change, a security incident at the vendor, or a material change in what data flows.

Tie it to a control you already run. If you do quarterly access reviews, do AI discovery in the same sitting.

Where it connects to compliance

This is not a separate regime. SOC 2 and ISO 27001 already require vendor management, and AI vendors are vendors. ISO 42001 formalises the AI-specific layer if you need certification. The EU AI Act adds obligations based on what the system does. Building one register that serves all of them is far cheaper than three parallel efforts.

Our AI Vendor Risk Assessment stands this up end to end, the vendor questionnaire builder and shadow AI risk checker are free, and third-party risk management covers the wider programme this sits inside.

Real offensive depth

Audit-ready, fixed scope

Learn the space

OSFI B-13 and What It Means If You Sell to a Canadian Bank

Want the rest of this by email?

You may also like

SOC 2 for Crypto and Web3

Your SOC 2 Report Came Back With Exceptions. What That Actually Means

ISO 42001 Requirements: A Practical Checklist

Want a second opinion on where you stand?

Who is actually doing the work

Published vulnerability research

A SOC 2 Type II built from nothing

The first thing to understand

What to do in the first 48 hours

How to answer the ones you cannot answer yes to

What the questionnaire is really telling you

What good looks like six months later

What they are actually checking

What the document needs to contain

Write it to match reality, then improve reality

Where this leads

The three things they are checking

Why the attestation letter is the right artefact

If you have never had a test done

Scoping it so it satisfies the buyer and the auditor

Why this form is different

What they actually price on

The tested plan is the cheap one

Use the renewal date as the deadline

What actually gets examined

The answers that cost you

What to have ready before the room opens

Security as a raise asset

Find out what actually failed

Fix the blockers, not everything

Going back

The part that matters after the deal

Find out whether it is a hard requirement

If they will accept SOC 2

If it really is ISO 27001

What not to do

Why the gap exists

What it can and cannot say

Who signs it

When it stops being enough

What it has to contain

An example row

Excluding a control properly

The mistakes that cost a Stage 1

Exception, qualified opinion, adverse opinion

How buyers actually read them

What causes most exceptions

What to do now

What gets easier

What gets harder

The four things to put on a calendar

Watch the observation window

What to tell your auditor early

The timeline

What your auditor will want

Where renewals slip

Changing auditors at renewal

What it does well

What it cannot do

The honest split

Do you need to buy one

What you are affirming

Why it catches people out

What to do before signing

Flow-down does not pause

Why this control fails so often

The list has to be complete

The reviewer has to be able to judge

The record is the deliverable

A process small teams can keep up

What it has to cover

An example structure

The boundary mistakes

Carve-out versus inclusive