Compliance, explained.
Practical guides on frameworks, evidence, and running a compliance program like an engineering team.
Completing a PCI DSS Self-Assessment Questionnaire, step by step
The SAQ is short next to a full Report on Compliance, but it is still an annual evidentiary document with real legal weight. Treating it like a form-filling exercise is how programs end up missing things.
A SOC 2 readiness checklist
A SOC 2 audit is mostly won before the auditor arrives. This checklist runs the program in the order auditors expect to find it.
Cross-framework control mapping, explained
Most security frameworks ask for the same things in different words. Mapping is how you stop proving the same control five times.
COBIT 2019 focus areas
Focus areas are how COBIT zooms in on a topic — cybersecurity, DevOps, cloud — without abandoning the core model. They are the framework's specialised lenses.
COBIT 2019 vs COBIT 5: what changed
COBIT 2019 is an evolution of COBIT 5, not a revolution — but design factors and focus areas made it genuinely more tailorable.
COBIT 2019 vs the NIST CSF
COBIT governs IT broadly; the NIST CSF governs cybersecurity risk specifically. One is the wide governance frame, the other a focused security lens that slots inside it.
COBIT 2019 performance management
You cannot improve governance you do not measure. COBIT Performance Management is how the framework turns "are we governing well?" into a number you can track.
Roles and RACI charts in COBIT 2019
Governance fails on ambiguity about who owns what. COBIT's RACI charts make responsibility explicit — for every objective, who is Responsible, Accountable, Consulted, Informed.
COBIT 2019 for small business
COBIT is not only for big enterprises — its tailoring model is exactly what lets a small company take the parts that matter and leave the rest.
Using the COBIT 2019 Design Guide
The Design Guide is COBIT's instructions for making it yours — a workflow that turns generic objectives into a governance system shaped to your context.
COBIT 2019 enterprise and alignment goals
The enterprise and alignment goals are COBIT's shared vocabulary for "what the business wants" and "what IT must deliver" — the rungs of the goals cascade.
COBIT 2019 explained
COBIT is not a security framework — it is a governance framework for enterprise IT. It answers "is IT delivering value and managed well," not "are we secure."
The COBIT 2019 principles
COBIT 2019 rests on two sets of principles — one for what a good governance system looks like, one for the framework itself. They are the philosophy behind the structure.
The COBIT 2019 goals cascade
The goals cascade is COBIT's answer to "why are we doing this IT thing?" — it traces every IT objective back to an enterprise goal and a stakeholder need.
The five COBIT 2019 domains
COBIT's 40 objectives live in five domains — one for governance, four for management. Knowing the domains is the map to the whole framework.
COBIT 2019 EDM domain (Evaluate, Direct, Monitor)
EDM is the governance domain — the only one that is the board's job, not management's. It is where COBIT's governance/management split becomes concrete.
COBIT 2019 APO domain (Align, Plan, Organise)
APO is where IT gets its act together before building anything — strategy, architecture, risk, and the planning that the build-and-run domains depend on.
COBIT 2019 BAI domain (Build, Acquire, Implement)
BAI is where COBIT's plans become real systems — programs, projects, changes, and the discipline of implementing them without breaking what works.
COBIT 2019 DSS domain (Deliver, Service, Support)
DSS is the keep-the-lights-on domain — operations, service desk, incidents, and the security services that run every day, not just on audit day.
COBIT 2019 MEA domain (Monitor, Evaluate, Assess)
MEA is the domain that checks the others — performance, internal control, and compliance. It is how COBIT closes the loop and feeds governance with evidence.
COBIT 2019 governance and management objectives
COBIT's 40 objectives are the framework's working units. You do not implement all of them equally — you prioritise the ones your goals and risk demand.
COBIT 2019 governance components
Components are COBIT's recognition that governance is not just process — it is also structures, culture, skills, and information working together.
Implementing COBIT 2019
You do not "install" COBIT — you improve toward it, one prioritised cycle at a time. The implementation guide is about change management as much as governance.
COBIT 2019 vs ITIL
COBIT governs IT; ITIL runs IT services. They are complementary layers, not competitors — COBIT sets the what and why, ITIL the how of service delivery.
COBIT 2019 vs ISO 27001
COBIT is broad IT governance; ISO 27001 is deep information security. One is wide and shallow, the other narrow and deep — and they map together.
An ISO 42001 readiness checklist
ISO 42001 looks large until you list it out. For most organisations it is an AI inventory, a risk and impact assessment, the AI-specific controls, and the management machinery.
Getting started with ISO 42001
Start where the risk is: inventory your AI, assess it, and build the management system around the systems that actually matter.
The ISO 42001 AI risk assessment
An AI risk assessment looks outward in a way a security one does not — at the people the system affects, not just the assets it runs on.
AI system impact assessment under ISO 42001
The impact assessment is where AI governance gets serious about people — documenting who a system affects and how, before it affects them.
Data governance under ISO 42001
ISO 42001 puts data governance at the centre because most AI risk is really data risk wearing a model's clothes.
Transparency requirements in ISO 42001
Transparency is the control that makes the others possible — you cannot oversee, contest, or trust an AI system you are kept in the dark about.
Human oversight under ISO 42001
ISO 42001, like the EU AI Act, wants humans who can actually understand and override AI — not ones who reflexively approve whatever the model says.
The AI system lifecycle in ISO 42001
AI risk is not a launch-day event — it shifts across the lifecycle. ISO 42001 governs the whole arc, not just the model you shipped.
The ISO 42001 statement of applicability
The applicability statement is where you justify your AI control set — which Annex A controls you apply, which you do not, and why.
ISO 42001 internal audit
You audit your own AIMS before the certification body does — and an AI audit asks questions a security audit never would.
ISO 42001 management review
The management review is where leadership owns AI risk on the record — and given how fast AI moves, it is a review that actually has news.
AI objectives and measurement in ISO 42001
Responsible-AI goals you cannot measure are slogans. ISO 42001 asks for AI objectives with numbers — and proof you watch them.
Continual improvement in an AI management system
AI changes fast, so an AIMS that stands still falls behind. Continual improvement is the engine that keeps governance current with the technology.
Third-party AI under ISO 42001
ISO 42001 does not only govern the AI you build — it governs the AI you buy, which for most organisations is most of it.
How much does ISO 42001 cost?
ISO 42001 costs scale with how much AI you actually govern. A company consuming one AI API is a very different number from one building models.
Defining your ISO 42001 scope
Your AIMS scope decides which AI the certificate actually covers. Scope to the AI that matters — buyers and regulators read the boundary.
Risk assessment in the NIST CSF
Risk assessment is where the CSF stops listing assets and starts deciding what to worry about — the input that makes the whole program risk-based.
Access control in the NIST CSF
Access control is the highest-value cluster in Protect, and it is the same MFA-and-least-privilege work every other framework asks for.
Data security in the NIST CSF
Data security in the CSF is the CIA triad applied to your data — and it leans on the encryption and classification you build for every other framework.
Continuous monitoring in the NIST CSF
Continuous monitoring is the difference between detecting an incident and being told about it by a customer. It is the engine of the Detect function.
NIST CSF categories and subcategories, explained
The functions are the headlines; the categories and subcategories are where the actual work lives. Understanding the structure is how you use the CSF.
NIST CSF informative references
Informative references are why the CSF is a great organising layer: each outcome points to the 800-53, ISO 27001, and other controls that achieve it.
Using the NIST CSF quick-start guides
The quick-start guides are NIST meeting you where you are — short, audience-specific on-ramps into a framework that can otherwise feel abstract.
What is an AI Management System? ISO 42001 explained
ISO 42001 does for AI what ISO 27001 did for security: a certifiable management system for governing it responsibly across its lifecycle.
ISO 42001 vs ISO 27001
Same management-system DNA, different subject. ISO 27001 governs your information security; ISO 42001 governs your AI — and they slot together.
The ISO 42001 certification process
If you have certified to ISO 27001, ISO 42001 certification will feel familiar — the same two-stage audit, applied to your AI management system.
ISO 42001 Annex A controls
ISO 42001's Annex A is the AI-governance control set — the concrete things you do to manage AI responsibly, selected to fit your risk.
Writing an AI policy for ISO 42001
The AI policy is the apex document of your AI management system — leadership's statement of intent that every AI control hangs from.
ISO 42001 for startups
For an AI-first startup, ISO 42001 can be an early differentiator — if you keep the management system lean and tie it to the AI you actually ship.
The NIST CSF Identify function
You cannot protect what you have not identified. The Identify function is the inventory-and-understanding work the rest of the CSF builds on.
The NIST CSF Protect function
Protect is the function with the most controls — the safeguards that keep an incident from happening or contain it when it does.
The NIST CSF Detect function
Prevention fails eventually. Detect is the function that decides whether you notice in minutes or read about it in the news months later.
The NIST CSF Respond function
Respond is incident response by another name. The function asks whether you have a plan, follow it, and communicate — not whether you panic well.
The NIST CSF Recover function
Recover is the function that gets you back to normal — and proves, through testing, that you actually can.
What is new in NIST CSF 2.0
CSF 2.0's headline is Govern — a sixth function that reframes cybersecurity from a technical checklist into an enterprise-risk discipline.
Getting started with the NIST CSF
The CSF does not hand you a to-do list. The way in is a current profile, a target profile, and the gap between them.
NIST CSF for small business
CSF 2.0 was rewritten with small businesses in mind. Used right, it is a flexible, free way to build a real security program without a compliance budget.
NIST CSF current and target profiles
The profile is the CSF's core mechanic: describe where you are, where you want to be, and let the gap write your roadmap.
Running a NIST CSF gap assessment
A CSF gap assessment is just the current profile meeting the target profile — and writing down everything in between.
NIST CSF vs NIST 800-53
The CSF is the map; 800-53 is the parts catalogue. Most companies use the CSF to organise and 800-53 (if at all) for control detail.
NIST CSF vs SOC 2
The CSF helps you build a security program; SOC 2 proves it to customers. One is the work, the other is the receipt buyers ask for.
Supply-chain risk in the NIST CSF
CSF 2.0 moved supply-chain risk to the front, into Govern — because for most organisations, the biggest risks now run through their vendors.
Asset management in the NIST CSF
Asset management is the least glamorous and most foundational CSF outcome. Skip it and every other function has blind spots.
Validating and evaluating AI systems before deployment
Monitoring tells you how the model behaves in production. Validation is meant to stop the worst behaviour from getting there in the first place.
Building an AI system inventory
Every AI governance framework starts the same way: know what AI you actually run. The inventory is the map the rest of governance draws on.
Classifying AI system risk
A spam filter and a hiring model are not the same risk. AI governance, like security, is risk-based — classify first, then spend effort where the stakes are.
Standing up an AI governance committee
AI decisions cut across legal, security, product, and data. A governance committee is how you stop those decisions from falling through the cracks between them.
Writing an AI acceptable use policy
Your team is already pasting things into AI tools. An AI acceptable use policy is how you make sure customer data and secrets are not among them.
Shadow AI: governing ungoverned AI use
Shadow AI is shadow IT on fast-forward. The tools are free, instantly adopted, and hungry for exactly the data you most need to protect.
Data governance for AI systems
Garbage in, liability out. The EU AI Act and ISO 42001 both put data governance at the centre — because most AI risk traces back to the data.
AI bias and fairness in practice
AI bias is rarely malice — it is unrepresentative data and unexamined proxies. The governance question is whether you looked, and what you did when you found it.
Human oversight of AI systems
A human "in the loop" who always clicks approve is not oversight. Meaningful oversight means the human can actually understand and override the system.
AI explainability and transparency
You cannot oversee, contest, or trust a decision you cannot understand. Explainability is the control that makes the other AI controls possible.
AI model cards and documentation
A model card is the spec sheet for an AI system — what it does, how it was trained, where it fails. It is becoming table stakes for governed AI.
AI red teaming
Red teaming is penetration testing for model behaviour — deliberately trying to make the AI do the things it should not.
AI prompt injection and LLM security
Prompt injection is the SQL injection of the LLM era: untrusted text that the model treats as instructions. There is no perfect fix — only layered defence.
Managing third-party LLM and AI vendor risk
You probably buy your AI, not build it. That makes AI governance largely a vendor-management problem — with some sharp, AI-specific edges.
Monitoring and logging AI systems
A model that was fine at launch can quietly degrade as the world changes. Monitoring is how AI governance survives contact with production.
The AI bill of materials (AIBOM)
You cannot govern or secure an AI system whose ingredients you cannot list. The AIBOM is the ingredient label for AI — models, data, and dependencies.
A practical HIPAA compliance checklist
HIPAA looks sprawling until you list it out. For a tech business associate it comes down to a risk analysis, the safeguards, BAAs, and a breach process — done and documented.
The HIPAA minimum necessary standard
HIPAA's minimum necessary rule is least privilege for health data: people see only the PHI they need for their job, nothing more.
HIPAA audit controls
HIPAA wants a record of who touched ePHI. After a breach, that audit log is the difference between "we know what happened" and a guess.
HIPAA encryption requirements
"Addressable" does not mean optional. With ePHI it means: encrypt it, or write a very good explanation of why you did not — and there rarely is one.
The HIPAA Omnibus Rule, explained
The Omnibus Rule is why your SaaS is directly on the hook for HIPAA — it extended liability from covered entities to their business associates and subcontractors.
HIPAA enforcement and penalties
HIPAA fines scale with how culpable you were, and willful neglect is the expensive tier. "We did not know" is only a defence if you genuinely could not have.
HIPAA de-identification: Safe Harbor and Expert Determination
Data that is properly de-identified is no longer PHI — and no longer your HIPAA problem. There are exactly two approved ways to get there.
The HIPAA right of access
The right of access is the HIPAA rule OCR fines most. Patients get their records, promptly, at reasonable cost — and "we were slow" is an expensive answer.
The HIPAA contingency plan
HIPAA's contingency plan is BC/DR for health data, with one part the law makes non-negotiable: you must back up ePHI and be able to restore it.
HIPAA vs SOC 2: do you need both?
HIPAA is the law; SOC 2 is the proof your customers ask for. Handling health data, you often end up doing both — and the work mostly overlaps.
HIPAA vs HITRUST: what is the difference?
HIPAA tells you what to do; HITRUST gives you a certificate that proves you did. In healthcare, big buyers increasingly ask for the certificate.
HIPAA risk management vs risk analysis
The risk analysis finds the risks to ePHI; risk management does something about them. HIPAA requires both, and skipping the second is a classic finding.
HIPAA workforce training
Everyone who touches PHI needs HIPAA training — and the record proving they got it. It is mostly your security awareness program with a health-data lens.
HIPAA incident response
Not every security incident is a HIPAA breach — but you need a process that can tell, fast, because the breach clock starts at discovery.
HIPAA subcontractor BAAs
Your obligations flow downhill. Every subcontractor that touches your customers' PHI needs its own BAA with you — and many vendors miss this.
ISO 27001 vs ISO 27002
You get certified to 27001 and you implement using 27002. One is the requirement; the other is the how-to manual for the controls.
The documented information ISO 27001 requires
ISO 27001 names the documents you must keep — fewer than people fear. The trap is producing documentation the standard never asked for.
ISO 27001 surveillance audits and recertification
The certificate lasts three years, but the auditor comes back every year. Surveillance audits are how the certification stays honest.
ISO 27001 leadership and roles (Clause 5)
ISO 27001 will not let leadership delegate security and walk away. Clause 5 makes top-management ownership an auditable requirement.
ISO 27001 security objectives and measurement
Objectives you cannot measure are wishes. ISO 27001 asks for security goals with numbers behind them — and proof you actually watch them.
The ISO 27001 risk treatment plan
The risk assessment finds the risks; the risk treatment plan does something about them. One without the other is half a control.
Continual improvement in an ISMS
An ISMS that looks identical year to year is, by ISO 27001's logic, not being managed. Continual improvement is the engine the whole standard assumes.
HIPAA for SaaS and tech companies
You do not have to be a hospital for HIPAA to apply. Touch PHI on behalf of a covered entity and you are a business associate, on the hook.
HIPAA administrative safeguards
The administrative safeguards are most of the Security Rule, and they are about process, not technology — risk analysis, training, access management, and incident response.
HIPAA technical safeguards
The technical safeguards are the engineering half of HIPAA — and they map almost one-to-one onto the access, logging, and encryption controls you already build.
HIPAA physical safeguards
Like ISO 27001's physical controls, most HIPAA physical safeguards are inherited from your cloud provider — but your laptops and your media disposal are still on you.
The HIPAA Breach Notification Rule
HIPAA does not just ask you to prevent breaches — it dictates exactly who you tell, and when, if one happens. Encryption is the safe harbour.
What is an ISMS? ISO 27001 explained
ISO 27001 does not certify that you are secure. It certifies that you run a managed, improving system for staying secure — that distinction is the whole framework.
The ISO 27001 certification process
ISO 27001 certification is a two-stage external audit on top of your own internal audit. Knowing the sequence keeps the timeline honest.
Running an ISO 27001 internal audit
The internal audit is not a dry run you fake — it is a required control, and a real one catches the gaps before the external auditor does.
The ISO 27001 management review
The management review is where leadership owns the ISMS on the record. Skip it or fake it and you have a major nonconformity.
How much does ISO 27001 cost?
The certification body is a recurring line item SOC 2 does not have. Scope and internal time are still the bigger numbers.
ISO 27001 timeline: how long to certification
ISO 27001 is gated by your ISMS needing to actually run for a while before it can be audited — you cannot certify a system with no operating history.
Defining your ISO 27001 scope
Your certificate is only as meaningful as its scope statement. Scope too wide and you drown; too narrow and buyers notice.
ISO 27001 Annex A: organizational controls (A.5)
A.5 is the biggest Annex A theme and the most policy-heavy. It is also where most of your existing governance already lives.
ISO 27001 Annex A: people controls (A.6)
A.6 is the people theme: hiring, training, offboarding, and the rules of working. Most of it lives with HR as much as security.
ISO 27001 Annex A: physical controls (A.7)
For a cloud-first company, A.7 is mostly inherited from your data-centre providers — but "we use AWS" is an answer you still have to document.
ISO 27001 Annex A: technological controls (A.8)
A.8 is where the engineering lives: access, crypto, logging, secure development, and network security. It overlaps almost entirely with SOC 2's technical controls.
ISO 27001 nonconformities and corrective action
A nonconformity is not failure — an audit with zero findings is more suspicious than one with a few. What matters is how you close them.
ISO 27001 for startups
ISO 27001 looks heavier than SOC 2 because of the management-system machinery. For a startup, the trick is keeping that machinery small but real.
How to answer a security questionnaire
A security questionnaire is a sales document in disguise. Answer it like one: accurate, confident, and backed by evidence you can produce on request.
Encryption at rest and in transit
Encryption is the control everyone claims and few fully cover. The gaps are always the same: a backup, an internal hop, a key in a config file.
Writing a data retention policy
Most retention policies describe a discipline nobody actually follows. The value is in the deletion that actually happens, not the schedule on paper.
A practical data classification scheme
Four tiers is plenty. The mistake is a beautiful classification scheme that nobody applies to actual data.
Building an asset inventory auditors trust
Every framework assumes you know what you own. A stale inventory quietly invalidates half your other controls.
How to build a risk register
A risk register is only useful if risks move through it — identified, owned, treated, reviewed. A static list is just anxiety in a spreadsheet.
Security awareness training that counts
Awareness training is mocked because most of it is theatre. Done right it is one of the cheapest defences against the attacks that actually land.
Secure offboarding, step by step
Lingering access from departed employees is one of the most common — and most dangerous — audit findings. Make offboarding a checklist, not a memory.
A password policy that matches modern guidance
Forced 90-day rotations and complexity gymnastics are out. Length, screening against breached passwords, and MFA are in.
Writing an acceptable use policy
The AUP is the one policy every employee should actually read. Write it for them, not for the auditor.
Which compliance framework should you do first?
Do the framework your customers are actually asking for — not the one that looks most impressive. Demand, not prestige, picks the order.
Compliance for fully-remote teams
A remote company has no network perimeter — so identity and the endpoint become the perimeter. Build the controls around those.
Shadow IT: the compliance blind spot
The riskiest vendor in your stack is the one you do not know you have. Shadow IT is where your carefully-built controls have gaps you cannot see.
Change management for SOC 2
You almost certainly already do change management — it is called code review. The SOC 2 work is mostly proving the review and approval happened.
The SOC 2 risk assessment
The risk assessment is not paperwork for the auditor — it is supposed to explain why you chose the controls you did. Write it so it actually does that.
Logging and monitoring for SOC 2
Collecting logs is the easy half. SOC 2 wants evidence that someone notices when they say something — alerts that fire and get actioned.
Encryption controls for SOC 2
SOC 2 is principles-based, so there is no "use AES-256" rule — but a report without TLS everywhere and encryption at rest will draw questions fast.
Business continuity and disaster recovery for SOC 2
A disaster recovery plan you have never tested is the most common BC/DR finding. The test is the control; the document is just the script.
SOC 2 exceptions and qualified opinions
Buyers read the opinion and the exceptions, not just the logo. Knowing the difference between a noted exception and a qualified opinion is how you read — and pass — a report.
Choosing your SOC 2 observation period
Three months gets you a report fastest; twelve gives buyers the most assurance. Pick the window for the deals in front of you, then settle into an annual rhythm.
The SOC 2 gap assessment
Before you hire an auditor, find out what is missing. A gap assessment turns "are we ready?" into a dated to-do list.
The SOC 2 controls list: what to expect
SOC 2 does not hand you a control list — you derive it from the criteria. Here are the families that appear in essentially every report.
Is a penetration test required for SOC 2?
Strictly, SOC 2 asks for a vulnerability management program — not a specific pen test. In practice, buyers ask for the pen test report, so most teams run one.
Network segmentation to shrink PCI scope
Everything that can reach the cardholder data environment is in scope. Segmentation draws the boundary — done well, it can take dozens of systems out of your SAQ.
PCI compensating controls, done right
A compensating control is not an excuse to skip a requirement. It is a different control that meets the intent and rigour of the original — and it has to be justified in writing.
Tokenization for PCI scope reduction
If your systems only ever hold tokens, most of them fall out of PCI scope — because a token, on its own, is worthless to an attacker.
PCI DSS penetration testing requirements
A penetration test is not the same as an ASV scan, and not every merchant needs one. Here is what PCI actually requires and when.
PCI DSS multi-factor authentication requirements
PCI DSS 4.0 pushed MFA well beyond remote admin access. If card data is involved, the bar is now "MFA for all access into the CDE."
How much does a SOC 2 actually cost?
The auditor invoice is only part of the bill. The bigger costs are scope, internal time, and whether you do a Type I first.
SOC 2 timeline: how long it really takes
The work you control takes weeks; the observation period takes months. Knowing which is which keeps your sales promises honest.
SOC 2 evidence collection without the scramble
A SOC 2 is an evidence exercise. The teams that suffer are the ones who try to assemble a period's worth of proof in the final week.
SOC 2 for startups: the lean path
Your first SOC 2 should be the smallest one that unlocks the deals in front of you — not a monument to every control you might one day need.
Access reviews that pass a SOC 2 audit
Access creep is the most common audit finding there is. A repeatable quarterly review closes it — and the same record credits PCI and ISO too.
Vendor management for SOC 2
Your SOC 2 covers your controls — but your vendors hold your customers' data too. Auditors want to see you manage that risk, not just list the logos.
Least privilege access, in practice
Least privilege is not a one-time grant — it is a habit of giving the minimum and taking it back. The proof an auditor wants is the taking-back.
Rolling out MFA everywhere
MFA is the single control that stops the most attacks for the least effort. The work is not turning it on — it is leaving no account behind.
Penetration testing vs vulnerability scanning
A scan tells you what is exposed; a penetration test tells you what an attacker could actually do with it. Most programs need both — but not always.
Tiering third-party vendors by risk
Treating every vendor the same is how third-party risk management dies of its own weight. Tier by the data they touch, then spend your effort accordingly.
Do I need a QSA for PCI DSS?
Most small and mid-sized merchants can self-assess with an SAQ and sign their own AOC. A QSA is required only at the top — here is exactly where the line sits.
Inside the PCI Attestation of Compliance (AOC)
The SAQ is the work. The AOC is the one signed page that proves you did it — and the document your acquirer actually files.
Security policies auditors accept
A policy is not a wish list. Auditors test whether it is approved, current, communicated, and actually followed — write for that.
What a Data Processing Agreement (DPA) must contain
If a vendor handles personal data on your behalf, you owe a DPA. Here is what a defensible one actually contains.
Incident response that satisfies SOC 2, PCI, and ISO at once
You do not need three incident response plans. You need one good one, tested, that every framework can credit.
Access reviews that pass an ISO 27001 audit
Access creep is the most common audit finding there is. A repeatable review closes it — and one record satisfies four frameworks.
The HIPAA policies and procedures you actually need
HIPAA does not hand you a checklist of documents. Here is the practical policy set that satisfies the Security Rule safeguards.
The NIST AI RMF Generative AI Profile, in practice
The Generative AI Profile is the AI RMF customised for the systems your teams are actually shipping. Twelve risk areas, mapped to Govern, Map, Measure, Manage.
AI incident response: building the runbook
Your existing IR runbook does not cover the failure modes that matter for AI systems. Build the AI-specific one before you need it.
AI governance for startups: a 30-day starter plan
You do not need ISO 42001 certification on day one. You do need to answer the AI questions in customer questionnaires without flinching.
The complete PCI DSS SAQ walkthrough: a step-by-step guide
Most SAQ guides stop at "pick the right type." This one walks the entire cycle end-to-end — what to gather before you start, how to read each requirement, what evidence actually satisfies it, and what happens after you submit.
SAQ A walkthrough: fully outsourced e-commerce
SAQ A is among the shortest PCI SAQs but the easiest to misuse. The eligibility bar is strict; the 4.0.1 script controls trip up almost everyone the first year.
SAQ A-EP walkthrough: e-commerce that partly controls the payment
SAQ A-EP is what you actually need when your payment page is "mostly outsourced." Substantially heavier than A; substantially shorter than D.
SAQ B walkthrough: standalone dial-out terminals
SAQ B is the smallest PCI SAQ. It assumes a very narrow setup — and the moment your terminal touches IP, you switch to SAQ B-IP.
SAQ B-IP walkthrough: standalone IP-connected terminals
SAQ B-IP sits between SAQ B and SAQ C. The terminal is "smart" (IP-connected) but standalone (not integrated into a POS system).
SAQ C walkthrough: payment application on an internet-connected POS
SAQ C is for the integrated POS case: a payment application on a system you operate, connected to the internet, no card storage. Heavier than B-IP, lighter than D.
SAQ C-VT walkthrough: virtual terminal on a dedicated computer
SAQ C-VT is narrow: a virtual terminal in a browser, one computer, one transaction at a time, no storage. The "isolated computer" requirement is the hard bit.
SAQ P2PE walkthrough: validated point-to-point encryption
SAQ P2PE is the shortest SAQ and the most attractive — but only if you use a PCI-listed P2PE solution. Self-built "encryption" does not qualify.
SAQ D-Merchant walkthrough: when none of the others fit
SAQ D-Merchant is the comprehensive SAQ. If you do not qualify for A through P2PE, this is where you land — closest to a full ROC in coverage.
SAQ D-Service Provider walkthrough
Service providers carry obligations merchants do not. SAQ D-Service Provider is the eligible self-assessment route for service providers below the Level 1 threshold.
AI impact assessments: ISO 42001 and the EU AI Act
The impact assessment is the one document that survives every audit you face on an AI system. Build it once with both standards in mind.
AI vendor due diligence: the questions to ask
A standard vendor questionnaire was built for SaaS that does not change underneath you. AI vendors do. Here is what to add.
ISO 42001 vs NIST AI RMF: a side-by-side
Both produce defensible AI governance. They are not interchangeable, and you can comfortably implement both.
Is your AI system high-risk under the EU AI Act?
Most AI Act compliance work attaches to the high-risk tier. Knowing whether your system is in it is the most consequential reading you do all year.
OWASP LLM Top 10 for security teams
OWASP's LLM Top 10 is the closest thing the GenAI security space has to a shared vocabulary. Treat it as a threat-model checklist, not a compliance bingo card.
NIST AI Risk Management Framework: the four functions
NIST CSF for AI, with a twist. Same structural elegance, applied to an AI system you have actually scoped.
EU AI Act timeline: what applies, and when
You probably do not need to be ready for all of the AI Act today, but two of its phases are already in force. The rest land on a published calendar.
ISO 42001 vs EU AI Act: how they complement each other
Two different instruments answering related questions. Confusing them costs time and money; treating them as complementary is how mature programs use both.
Writing the SOC 2 System Description (Section 3)
A SOC 2 report has four sections. Section 3 — the System Description — is the one written by management, and the one auditors test against. Get it wrong and you earn a qualified opinion.
SOC 1 vs SOC 2 vs SOC 3: which report do you actually need?
The "SOC" family is three reports with the same brand and three different purposes. Pick the wrong one and you spend a quarter producing assurance that no buyer asked for.
Vendor risk management, explained
Your compliance posture includes the vendors that touch your data. Auditors know it, frameworks require it, and a spreadsheet of questionnaires is not a program.
NIST CSF vs ISO 27001: how to choose (and how to run both)
NIST CSF is a map. ISO 27001 is a system. You can read a map without running a system, but you cannot run a system without a map.
COBIT 2019 design factors and tailoring
Trying to run all 40 COBIT objectives at full intensity is how programs die quietly. The design factors are how the framework was designed to be scaled down to your context.
A compliance audit readiness checklist
Audits go badly when readiness is assembled the week before. Here is what to have standing, in roughly the order an auditor will ask for it.
HIPAA Business Associate Agreements: when you need one and what it must contain
If your software touches PHI on behalf of a covered entity, you are a business associate. A signed BAA is the price of doing the work — and the obligations that come with it are not just contractual.
SOC 2 bridge letters: what they are and when to send one
A SOC 2 report covers a finite window. Customers who rely on it want assurance that nothing has changed between that window and today — that is what a bridge letter is for.
SOC 2 or ISO 27001: which should you do first?
They overlap heavily, but they are not interchangeable. The right first choice depends on who is asking and where your buyers are.
ISO 42001 explained: the AI management system standard
For organisations developing or deploying AI systems, ISO 42001 is what ISO 27001 was for information security: a defensible, certifiable management system that buyers and regulators will start to expect.
HIPAA Security Rule: administrative, physical, and technical safeguards
The 18 standards in the Security Rule are the spine of any HIPAA program. Knowing what is required versus addressable is the difference between a clean audit and a tense conversation with OCR.
PCI DSS non-compliance: fines, fees, and downstream costs
PCI is enforced through contracts, not statutes. That makes the penalties less visible than a regulatory fine — and often more expensive once you add them up.
What changed in ISO 27001:2022 Annex A
The 2022 revision is structural, not philosophical. Most of the old controls survived under new numbers; the change is in the grouping and the 11 controls that did not exist before.
PCI DSS scope reduction: how to shrink your CDE
Every system in your cardholder data environment is a system you have to secure and assess. The cheapest control is the one you remove from scope entirely.
NIST CSF Profiles and Implementation Tiers
A CSF assessment that does not use Profiles and Tiers is a list of yes/no answers without a destination. They are the framework's mechanism for "right-size this to my organisation."
PCI DSS quarterly ASV scans: what they cover and how to pass
ASV scans are the most visible recurring PCI obligation: four passing attestations a year on every internet-facing system in scope. Knowing how the scan thinks is how you stop them from owning your quarter-end.
COBIT 2019 capability levels (0–5), explained
COBIT 2019 rates each objective on a 0–5 capability scale. Knowing what each level means turns a governance assessment into a roadmap.
COBIT 2019 governance objectives vs management objectives
Governance directs. Management plans, builds, runs, monitors. COBIT 2019 makes the distinction explicit because confusing the two is how IT investments end up disconnected from enterprise value.
ISO 27001 risk assessment and treatment under clause 6.1
A good ISMS is a chain of decisions: identify risks, evaluate them, treat them, and document the result. Clause 6.1 is where that chain is built, and where most certification findings start.
HIPAA Security Rule risk analysis: what is required
The risk analysis is the foundation of HIPAA Security Rule compliance — and the single most common finding when something goes wrong.
HIPAA Privacy Rule vs Security Rule: what each covers
Engineers tend to default to "the Security Rule" when they say HIPAA. Most procurement reviews and breach notifications start with the Privacy Rule. Knowing the difference matters.
NIST CSF 2.0: the new Govern function explained
CSF 2.0's biggest change is a new function that wraps the other five: Govern. It moves cybersecurity from a technical checklist to an enterprise-risk discipline.
NIST CSF 2.0 core functions: Govern, Identify, Protect, Detect, Respond, Recover
The Cybersecurity Framework is a conceptual map, not a control checklist. Knowing the six functions cold is how you have a useful conversation with executives, customers, and procurement.
Manual vs continuous compliance evidence
Screenshots taken the week before an audit prove one thing: that the control worked once, under observation. Continuous evidence proves it works.
SOC 2 Common Criteria (CC1 to CC9), explained
Every SOC 2 report covers the same nine Common Criteria categories. Knowing what each one expects is how you stop a friendly Type I conversation from turning into a list of management responses.
PCI scoping: identifying your cardholder data environment
The PCI requirements only apply to systems in scope. Defining scope is the first and most consequential decision in any assessment, and the easiest one to get wrong.
The ISO 27001 Statement of Applicability, done right
The SoA is the single document a certification auditor measures everything else against. Get it right and the audit goes smoothly.
ISO 27001 mandatory clauses 4 to 10, explained
ISO 27001 is a management system standard. The 93 Annex A controls are the visible half; clauses 4 to 10 are the management system itself, and they decide whether the audit goes well.
PCI DSS service provider levels and what SaaS owes
If your software handles card data on behalf of your customers, you are a service provider in the PCI DSS sense. The customer-facing AOC you owe is one of the most common compliance artifacts you will be asked for.
SOC 2 Type I vs Type II: which do you need?
A Type I proves your controls are designed well today. A Type II proves they actually worked over months. Most buyers want the second one.
The five SOC 2 Trust Services Criteria, explained
A SOC 2 report covers five Trust Services Criteria, but only one is mandatory. Picking the rest is a scoping decision driven by what you promise customers.
Which PCI SAQ type applies to you?
The right SAQ depends entirely on how you handle card data. Pick the wrong one and you either over-report or, worse, under-scope.
PCI DSS 4.0.1: what changed and how to prepare
PCI DSS 4.0 (refined as 4.0.1) is the largest revision of the standard in a decade. Here is what actually changed, and a pragmatic order to tackle it.
PCI DSS merchant levels (1 through 4), explained
Your merchant level decides the validation path. Knowing where you sit, and what triggers a promotion, is the difference between a quarter of self-assessment work and a year of ROC fieldwork.
What is a GRC platform?
GRC stands for governance, risk, and compliance. A GRC platform is the system of record that ties all three together instead of scattering them across spreadsheets.
No articles match your search.
Try a broader term or clear filters.