Methodology addendum to I scanned 15 Italian citizenship agencies for basic security

1. Relationship to the original post

The original post is dated 23 March 2026 and remains available at the canonical URL given above. Earlier archived copies, including those held by the Internet Archive, are equally available and have not been altered; the original is preserved as published.

This addendum does not amend the claims in the original post. Where the original post made a statement of fact, the statement still stands and is supported by the material set out below. Where the original post offered an opinion drawn from those facts, the opinion still stands and the basis for it is identifiable in the same material.

What this addendum adds is depth. The detail of how the sample was chosen, what each scan request looked like, how the grade was computed, why agencies were not named, and how the right of reply works was either present in the original at a higher level or implicit in the underlying tool. Setting it out here in full removes that gap.

2. Sample selection

Fifteen organisations were selected from the first page of results returned by Google.com searches in private mode, from a UK exit IP address, on 22 March 2026 between 19:30 and 21:00 UTC, for the search terms jure sanguinis service and Italian dual citizenship agency. The sampling rule was: take the first fifteen distinct organisational domains returned across both searches in order of first appearance, excluding pages of an obvious non-commercial nature (Wikipedia, government sites, journalism, online forum posts).

The sample is therefore time-bounded and search-engine- bounded. It is not a representative sample of the global population of services described as offering Italian citizenship assistance; it is the slice of that population most visible to a UK-based prospective client carrying out the search above on those dates. Different geographies, search terms, and dates would produce different samples.

The list of organisations selected is held privately and isn’t published, for the reasons set out in section 7. It’s recorded in the editorial file for the post.

3. The scan

Each sampled domain was scanned once on 23 March 2026 using the beacon scanner described at /projects/beacon. The full technical methodology of the scanner is at /methodology; the summary is that beacon performs seven categories of check: TLS inspection, response headers from a single unauthenticated GET, public DNS records for SPF, DKIM and DMARC, twenty-five common exposed paths with body-shape validation, third-party tracker detection from the static HTML, form action targets, and cookie flags.

The scans were conducted from the hosted version of the scanner running on my infrastructure. No authentication was attempted against any sampled domain. No payload was submitted to any form. No request was constructed to test or trip a known vulnerability class. No request was made to a path beyond the published list of twenty-five common exposure paths. Each scan produced a single grade and a set of annotated findings. The aggregate counts cited in the original post (87% missing effective DMARC, 13 of 15 missing CSP, 12 of 15 loading Google Analytics, 0 of 15 with a security.txt, and so forth) are the simple counts of the boolean findings across the fifteen scans on that date.

The author has retained the raw scan results from 23 March 2026 as a JSON archive in the editorial file. Where a domain has reconfigured its public surface since the scan, the raw archive remains the record of what was observed at the time of scanning; it is not, and is not offered as, a record of the current state of any organisation.

4. Grading

beacon assigns each domain a letter grade from A to F. The grade is derived by point deduction from a base of 100, with weights set in source as 40 for a critical finding, 20 for a high finding, 8 for a medium finding, and 2 for a low finding. Two floor rules apply: any single critical finding sets the grade to F; two or more high findings cap the grade at no better than D.

Severity is not absolute. beacon applies an industry profile to the same finding so that a missing DMARC record on, for example, a restaurant website is assessed differently from a missing DMARC record on a service handling immigration documents and payment instructions. For the sample in this post, the scans were run under the immigration profile. Under that profile, the absence of an effective DMARC policy is treated as critical because business-email-compromise fraud is documented at scale across that sector and because the data the sector handles (passport copies, financial details, identity documents) is high-value to the attacker class associated with that fraud. The choice of profile is editorial and is recorded here so that a reader can challenge it.

The fourteen F grades and one D grade reported in the post are the direct outputs of these rules applied to the scan results from 23 March 2026.

5. Why the agencies were not named

The original post discusses the sample anonymously. The choice was made before publication, not after, and the reasoning was as follows.

The public interest served by the post is the public’s interest in understanding the externally visible security posture of the sector. That interest is fully served by describing the aggregate state of the fifteen domains: how many had effective DMARC, how many used session- recording tools on forms, how many exposed an admin login page. Naming individual organisations would not increase the public’s ability to understand the sector; it would shift the post from a statement about the sector to a list of accusations against fifteen specific entities.

Naming would also raise the per-organisation threshold of evidence required. Section 4 of the Defamation Act 2013 permits publication on a matter of public interest where the defendant reasonably believes that publication is in the public interest, judged with regard to the circumstances. An aggregate post about a sector clears that bar more easily than a list of individual accusations would. The choice to publish in aggregate is therefore both an editorial choice and a posture that keeps the post within the most defensible reading of the statute.

The author is conscious that a sufficiently determined reader could re-derive the sample by repeating the same search at a later date. Two points limit this:

• The search results for the same terms are not stable across time. Repeating the search a month later does not return the same fifteen domains in the same order.
• The findings are not stable across time either. An organisation that lacked an SPF record on 23 March 2026 may have configured one since. The scan archive is the record of what was observed, not the record of what is true now.

Where, despite these limits, a specific organisation considers itself substantially identifiable from context and contests a finding, the right of reply in section 8 is the route to address that.

6. Why this was published

The editorial test for this post was the same one applied to anything here that touches a real organisation: is the finding factually verifiable, does a reasonable reader need it at the point of decision, and is the wording proportionate to what was actually observed? All three were yes.

The findings are configuration facts about the public surface (no DMARC, no CSP) — not allegations of fraud or criminal conduct, and the language stays in the register of the configurations themselves. The audience makes decisions about who holds their passport copies and payment instructions; the sector handles identity documents and personal data for people who often have limited alternatives.

On verification: the tool is open source, the methodology is published at /methodology, and a reader who doubts any finding can rerun the scan within the hour. The scanner uses double-resolution DNS and body-shape validators on every check; the aggregate counts are direct counts of validated findings. Each cited breach precedent is a primary source — ICO decision (British Airways CSP), FBI IC3 annual reporting (BEC fraud totals), Princeton academic study (session recording) — none of them is my own claim.

The post wasn’t rushed for traffic; it was held until the scan results were verified and the precedents checked. The agencies aren’t named, so the right-of-reply procedure at section 8 is the route for any organisation that recognises itself.

The tone is descriptive of technical findings. It doesn’t impute fraud or criminality and doesn’t call for any specific commercial consequence; where opinion appears (the closing line about what configuration habits in one area suggest about habits behind the login) it’s framed as opinion and rests on the published findings. Publication is on a self-hosted site under my own name, with a permanent URL and a date — not promoted via paid distribution and not directed at any organisation’s customers.

7. What was withheld

The following material exists in the editorial file for the post and was deliberately not published:

• The list of fifteen organisational domains. Withheld because naming would shift the post from aggregate reporting to individual accusation, for the reasons given in section 5.
• The raw response bodies returned by exposed-paths checks. Withheld because the bodies are not necessary to support the published findings and because their publication could be characterised as facilitating further unauthorised access to systems where the configuration has not since been corrected.
• The names of individual employees of any sampled organisation. The site is not a vehicle for grievance against individuals.
• Customer data of any kind. No content visible to the scanner identified an individual customer; if it had, that content would have been redacted before any publication.

Withheld material isn’t released informally on request. Where there’s a lawful basis to require it — for example a court order, a properly-served regulatory request, or co-operation with the ICO under a Section 142 information notice — I’ll comply.

8. Right of reply

An organisation that believes it was scanned for the post of 23 March 2026 and that a finding attributable to it is inaccurate may exercise a right of reply.

To exercise the right:

1. Email [email protected] from a verifiably-controlled address on the organisation’s primary domain.
2. Identify the organisation and the specific finding disputed.
3. State the basis on which the finding is said to be inaccurate (configuration was different at the time of the scan; the scan was attributed to the wrong organisation; the industry profile was applied incorrectly; or any other ground).
4. Provide any evidence the organisation wishes to be considered.

I respond within one calendar month from receipt, usually faster. Where the disputed claim is wrong on the facts, the post is corrected with a dated note at the top describing what was changed and why. Where the disagreement is about interpretation rather than fact, the organisation’s reply may be incorporated into the post in summary, with a link to the full reply if it’s been published elsewhere.

The window to write in runs forward indefinitely from the publication date — an organisation that finds the post a year later isn’t time-barred. Nothing in this addendum displaces or limits any statutory right an organisation may have.

9. Errata register

The following table records corrections made to the original post since publication. Where the table is empty, the post has not been corrected since publication.

10. Versioning

This addendum is versioned independently of the original post. Substantive changes to the addendum update the version number and the published date at the top. Earlier versions are kept and available on request.

The original post is the canonical record of what was published on 23 March 2026 and is not edited to bring it into line with later versions of this addendum. Any change to the original post takes the form of a dated note at the head of that post.