Editorial Standards

How we research, write, review, and correct everything we publish.

Who writes ForgeWork content

Every article on forge-work.com is written by the ForgeWork DFIR Team — security practitioners with hands-on incident response, forensics, and detection-engineering experience across EMEA. We publish as a team, not as individuals, to reflect the collaborative nature of incident response work and because operational security in our field sometimes requires that individual identities remain private.

How a post gets from idea to published

  1. Topic selection. We pick topics from live incident patterns, recurring practitioner questions, and gaps we encountered that existing references did not close. We do not publish speculative commentary on vendor announcements or breach news we were not involved in.
  2. Drafting. A primary author drafts from personal case experience and primary sources (MITRE ATT&CK, NIST SP 800-61, Microsoft Learn, AWS security docs, ENISA publications, Belgian CCB guidance, etc.).
  3. Peer review. At least one other team member with relevant operational experience reviews for technical accuracy before publication.
  4. Citation. Every article carries structured citations in its JSON-LD metadata and inline links to primary sources. We do not cite aggregators or secondary blogs as if they were primary.
  5. Publication. Posts are published with a publish date and are reviewed at least annually; the Last reviewed date is visible on every article.

What we do not do

Corrections policy

If you find a factual error in any ForgeWork article — a misquoted CVE, an outdated command flag, a wrong attribution, a broken procedure — email [email protected]. We aim to respond within three business days. Confirmed corrections are made directly in the article, the Last reviewed date is bumped, and a brief note appended at the bottom of the article describing what changed and when. We do not silently edit published content to obscure previous errors.

Updates and refresh cadence

DFIR content ages unevenly. Tool-specific procedures (command flags, log field names) can break within months; conceptual content (threat modelling, IR frameworks) holds for years. We review each article at least annually and update it any time we publish a newer article on the same topic, receive a correction, or encounter the same material in a live engagement and notice it needs changing.

Contact

Editorial questions, corrections, or source verifications: [email protected].