THE TRUFEND BLOG

The Outside View

What a domain scan can see from outside your systems, what it can't, and how to fix the things it finds. No badges, no scores dressed up as compliance.

01 4 POSTS

Understanding your report

What the grade means, what it covers, and what it deliberately does not claim.

SOC 2 explained as an iceberg: above the waterline, the visible tip is labelled with the Security, Availability and Confidentiality trust services criteria that an external domain scan can reach; below the waterline, the far larger submerged mass is labelled with Processing integrity, Privacy, and the people, processes and systems that only an auditor examining evidence can reach.

What SOC 2 is, and what it actually asks of you

SOC 2 explained: the trust services criteria, Type I against Type II, what an audit costs and takes, what is in the report, and the part no scan can reach.

Domain scan versus SOC 2 illustration: a small panel of passing external checks for TLS, certificate validity, open ports and known vulnerabilities, set against a far larger landscape labelled with the internal areas SOC 2 covers, including people and access, processes and policies, data protection, incident response, vendor management and risk governance.

Why we'll never call this a SOC 2 certificate

A domain scan could be dressed up as a compliance badge. Here's why Trufend's report deliberately isn't one, and what it reports instead.

Iceberg illustration: the fifth above the waterline is labelled with what scanners can see, including TLS and certificates, security headers, DNS records, public subdomains and exposed assets, while the far larger mass below is labelled with people and permissions, internal processes, access controls, backups and recovery, incident response and vendor management.

The 80% a domain scan can't see

SOC 2 is mostly process and internal architecture. Here's a map of what lives outside any scanner's reach - and why it matters more than the grade.

Trufend report illustration: a laptop showing a scan result for a domain with an overall grade, a list of security checks marked pass, issue or warning across TLS, DNS, subdomains, headers and infrastructure, and a readiness checklist of next steps alongside it.

How to read your Trufend report

A walkthrough of what the grade means, what the ten checks cover, and what to do with the checklist underneath them.

02 7 POSTS

What a scan can see

The signals your domain broadcasts to anyone who looks: TLS, DNS, email, headers.

Free server log analyser: a log window above a mountain range at dawn, showing access log lines with timestamps, 200 and 404 status codes and requested paths beside the user agent strings of Googlebot, Bingbot, AhrefsBot, ClaudeBot, GPTBot, SemrushBot, PerplexityBot and Applebot, with each crawler's route traced across the peaks below and a note that the log is read locally in the browser.

A free server log analyser that never uploads your log

See which search engines and AI crawlers really fetch your site, and what fails for them. Free, no line limit, and your log never leaves your browser.

External security posture illustration: a browser window showing a company domain, with callouts for DNS records, public subdomains, TLS certificate and protocol versions, exposed assets such as APIs and admin panels, and HTTP security headers.

External security posture: what anyone can see from outside your domain

The signals your domain broadcasts publicly: TLS, headers, DNS, subdomains and exposed assets, and what each tells a stranger.

SPF, DKIM and DMARC illustration: a legitimate email crossing a bridge through three authentication gates that ask whether the sender is authorised, whether the message was tampered with, and what to do on failure, while a spoofed message fails and is blocked before the recipient inbox.

SPF, DKIM and DMARC: stopping people sending email as you

What each of the three email authentication records does, how they work together, and exactly what to publish to stop your domain being spoofed.

Subdomain takeover illustration: a bridge that ends in mid-air at a cliff edge beside a sign reading service gone, labelled with a subdomain whose DNS record still points at a service that no longer exists.

Subdomain takeover: the DNS record that outlived the service

How a forgotten CNAME becomes someone else's page on your domain, why certificate transparency exposes subdomains, and how to audit them.

TLS certificate illustration: a mountain path marked with three waypoints for checking your configuration, disabling old protocols such as SSL and TLS 1.0 and 1.1, and renewing on time, above a panel showing a valid certificate with its issue and expiry dates.

Expiring and weak TLS: what breaks, and what to check

Why a lapsed certificate takes down login and API traffic instantly, which protocol versions to disable, and how to read your own TLS setup.

Exposed secrets illustration: a laptop showing a public code repository with a live API key highlighted on one line of a config file, and a scan panel reporting three secrets found, the API key rated high risk.

Exposed secrets: how API keys end up in public code

How keys end up in client-side bundles and public repositories, why scanners find them within minutes, and what to do when one leaks.

HTTP security headers illustration: layered translucent panels in front of a browser window, each labelled with a header and what it does, covering Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy.

The security headers that actually matter

What HSTS, CSP, X-Frame-Options, Referrer-Policy and Permissions-Policy each do, in what order to add them, and which one can break your site.

03 3 POSTS

Data isolation

Keeping one customer's data away from another's.

API key scope illustration: a narrowly scoped service-role key with limited access to specific resources beside an admin key with full access to every resource, the admin key ringed by a visibly larger blast radius, above an application connected to its database, services and APIs.

Scoping service-role and admin API keys

Why a service-role key bypasses every permission rule you have written, where these keys usually leak, and how to scope them down safely.

IDOR illustration: two customer accounts on opposite cliff tops, each holding its own profiles, orders, invoices and support tickets, with a request to another customer's record ID crossing between them and flagged as unauthorised access.

IDOR: can your customers see each other's data?

A ten-minute test with two accounts that finds the flaw scanners miss, and what to do when changing an ID returns someone else's record.

Row-Level Security illustration: a database table of orders where some rows are visible and others are locked and greyed out, labelled to show that each user sees only the rows their policy allows and that rows failing the policy stay hidden.

Row-Level Security: turning it on and checking it

How to confirm RLS is enabled on every table holding customer data in Supabase, Postgres or RDS, and why a table with no policies counts as off.

04 3 POSTS

Backups and resilience

What happens when something breaks, and how quickly you get back.

Graceful degradation illustration: an application on a mountain peak still online and serving users while one third-party API is marked unavailable and the payments, analytics and email services around it stay healthy, one of them on a fallback route.

When a dependency goes down, does your app break?

What happens to your app when Stripe, your mail provider or your database is unreachable, and how to fail in a way that keeps customers informed.

RTO and RPO illustration: a timeline along a mountain ridge from an outage, through the data loss window that the recovery point objective measures, to the restore time that the recovery time objective measures, ending at systems restored.

RTO and RPO: writing numbers you can actually defend

What recovery time and recovery point objectives mean in plain terms, how to pick numbers you can meet, and what auditors ask about them.

Restore testing illustration: data crossing a bridge from backup storage through a restore test that validates and verifies integrity, arriving at a restored and ready application with its data recovered.

Backups mean nothing until you restore one

How to run a restore drill, what to time, and the failure modes that only appear when you actually try to bring data back.

05 3 POSTS

Access governance

Who can reach what, and what happens when they leave.

API key rotation illustration: a weekly calendar with keys cycling through scheduled renewal, automated deployment of a new key, and automatic expiry of the old one, labelled to show rotation as a routine rather than an incident response.

Rotating API keys on a schedule, not after an incident

Why rotation matters more than key strength, how to rotate without downtime, and a realistic schedule for a small team.

Offboarding illustration: a checklist covering revoking access, disabling accounts, removing group membership, transferring ownership and confirming, connected to a departing employee whose access is removed across Google Workspace, Microsoft 365, Slack, GitHub, Salesforce and other applications.

The offboarding checklist that actually revokes access

The accounts people forget when someone leaves, why shared logins make offboarding impossible, and a checklist to hand to whoever does it next.

Multi-factor authentication illustration: a sign-in screen above a gate marked secure access only, requiring a second factor by phone approval or security key, labelled to show MFA as mandatory rather than optional.

Requiring MFA, not just offering it

The difference between MFA available and MFA enforced, how to check it in Google Workspace, Microsoft 365 and GitHub, and where gaps hide.

06 3 POSTS

Engineering process

The habits that stop an ordinary mistake becoming an incident.

Webhook signature illustration: signed events crossing a bridge into an application after their signature is verified, while an event with an invalid signature is rejected and blocked before reaching the app.

Verifying webhook signatures from Stripe and others

An unverified webhook endpoint accepts anything the internet sends it. How signature verification works, and how to add it in a few lines.

Secrets in source control illustration: a code editor showing a live API key highlighted in a config file, with pre-commit checks stopping secrets before they reach the repository, secret scanning detecting keys and tokens, and the credentials moving into a secure vault.

Keeping secrets out of your Git repository

Why deleting a committed key does not remove it, how to scan your history, and what to use instead of hardcoded credentials.

Branch protection illustration: feature and bugfix branches climbing to a pull request, through required code review and passing checks, before merging into a protected main branch that refuses direct pushes.

Branch protection: stopping direct pushes to main

How to require review on your main branch in GitHub or GitLab, what to do about solo maintainers, and why auditors ask about this first.

07 3 POSTS

People and policy

The written things an auditor asks for and an incident needs.

Security training illustration: new joiners walking a path marked with the topics onboarding should cover, including phishing awareness, access basics such as accounts and least privilege, device handling, and how to report a problem, beside a welcome checklist.

Security training for new hires and contractors

What training needs to cover, how to evidence that it happened, and why contractors are the gap auditors find most often.

Risk assessment illustration: a likelihood and impact matrix beside a list of treatment options covering mitigate, transfer, accept and avoid, with example risks including a data breach, a supplier outage, a service disruption and a regulatory change plotted by their likelihood and impact.

Documenting a risk assessment in an afternoon

A risk assessment is a list of what could go wrong and what you decided about it. How to write one that is honest and short enough to maintain.

Incident response plan illustration: a path from detection through containment, investigation and recovery, with panels describing the roles involved, the communications required, and the evidence to preserve at each stage.

What belongs in a written incident response plan

The five things a plan needs to be useful at 3am, what auditors look for, and why the phone number field is the one that fails in practice.

08 3 POSTS

Vendor management

Everyone else who touches your data.

Vendor security review illustration: three vendor cards showing what evidence each has provided across TLS, security headers, access controls, a SOC 2 report, subprocessors and vulnerability management, two rated low risk and one still needing review, beside a short review checklist.

Reviewing a vendor's security posture without a team

What to ask, what to accept as evidence, and how to review a critical vendor in an hour rather than a quarter.

Data processing agreement illustration: a signed DPA bridging a company acting as controller and a vendor acting as processor, listing the clauses it should cover including purpose and scope, types of personal data, security measures, sub-processors, data subject rights, and retention and deletion.

Data processing agreements: which ones you need

What a DPA actually commits a vendor to, which vendors need one, and how to get signed copies without a legal budget.

Vendor inventory illustration: a company application at the centre of a map of the external services that touch its data, including infrastructure, source control, collaboration, productivity, CRM, analytics, monitoring, payments and communications, with a count of vendors discovered and data categories.

Listing every vendor that touches your data

Start with your card statement. How to find the vendors you forgot, classify them by what they can see, and keep the list current.