A game reaches its QA team long before it reaches its players. Unreleased builds, bug reports, screenshots and production plans all tell a story that is not ready to be public. Looking after that information is part of looking after the game.
Pixel Bowl Studio has achieved ISO/IEC 27001 certification for its information security management system. For our team, this milestone reflects the importance of managing information responsibly alongside the testing, development and production support we provide.
For studios and publishers choosing a partner, it also creates a useful starting point for a more practical conversation: what information will we share, who needs access, and how will we work together throughout the project?
ISO/IEC 27001 sets requirements for an information security management system, often shortened to ISMS. It brings risk assessment, responsibilities and ongoing improvement into a structured approach to managing information. Its focus extends beyond IT equipment to people and working practices.
Keeping information accessible only to the people authorised to use it.
Maintaining information so it remains reliable and protected against inappropriate changes.
Making information accessible when authorised people need it for their work.
Reviewing risks and improving the management system as circumstances change.
Certification concerns the management system within its defined scope. It is not a certification of every game we test or a promise that no incident can ever happen. ISO develops the standard; independent certification bodies perform certification. Read ISO’s introduction to ISO/IEC 27001 and its explanation of certification.
In game QA, sensitive information can appear in ordinary work. A screenshot attached to a defect may reveal an unannounced character. A crash log may include an internal path or account identifier. A test plan may disclose an upcoming feature, while a release calendar can reveal a partner’s commercial plans.
That makes information security relevant to the whole workflow, from the initial brief to the final handover. The following examples show why the conversation needs to be specific to the project.
| Project material | Why it matters | What to agree |
|---|---|---|
| Unreleased builds and assets | May contain confidential gameplay, art or story content. | Who can access them and where they may be stored. |
| Bug reports and captures | Can expose the same content as the build itself. | Approved reporting tools, recipients and attachment handling. |
| Test accounts and credentials | May provide access to project environments. | Account ownership, permissions and access removal. |
| Logs and diagnostic files | May include identifiers or details about internal systems. | Which evidence is needed and how it should be shared. |
| Roadmaps and release plans | Can reveal commercially sensitive decisions. | Distribution, confidentiality and retention expectations. |
These are examples of planning considerations, not a claim that every engagement uses the same technical setup. A focused compatibility test and an embedded development QA team can have very different access needs.
Our certification journey brought together an assessment of our practices, implementation of the ISMS, staff awareness and audit preparation. It covered areas such as asset management, access control, information classification, risk treatment and business continuity procedures.
We began by examining our existing practices and identifying gaps against the standard’s requirements. That assessment helped turn a broad goal into a programme of work, with areas to address and a clearer understanding of the risks involved.
Policies need people who understand them. Staff training and awareness formed part of the journey, alongside the development of the management system. The aim was to connect security responsibilities with the way colleagues handle information during their working day.
Internal audits helped us assess the system and identify issues before the external certification assessment. Achieving certification marked an important milestone in that work. Maintaining the discipline behind it remains an ongoing responsibility.
The care we bring to a game should extend to the information entrusted to us.
A certificate helps start a supplier review, but productive collaboration still depends on understanding the engagement. Before work begins, it is useful to translate security expectations into clear project decisions.
Discuss the builds, tools and environments the team will need. Different roles may require different permissions, and those needs can change as the project evolves.
Choose the reporting channels and audiences for defects, captures and logs. A clear process helps useful evidence reach the right people without unnecessary copying.
Team changes, new platforms and additional tools can alter the information involved. Treat those changes as a reason to revisit the original arrangements.
Discuss what should happen to access, test accounts, files and project materials when a phase ends. Closing a project deserves the same clarity as starting one.
For procurement and security teams, the certificate’s scope, validity and applicability to the proposed work should form part of the discussion. Project-specific contractual requirements remain important alongside certification.
For production teams, the benefit is a more structured conversation about working together. Good QA needs timely access and useful evidence; good information handling helps define how both can be achieved responsibly.
Game production keeps changing. More hardware, distributed teams and new analysis tools introduce new decisions about where information goes and who can use it. AI-assisted workflows deserve particular attention when they involve unreleased content or project documentation.
Before introducing a tool into a confidential workflow, useful questions include whether it receives project data, how that data is retained, who can access it and whether the proposed use fits the partner’s requirements. These questions belong in the planning process, alongside the tool’s potential benefits.
At Pixel Bowl, our next steps build on the commitment behind certification: keep reviewing our practices, learn from experience and make information security part of the conversation as our work develops.
Tell us about your platforms, production stage and security expectations. We can discuss the support you need and the information required to assess the engagement.
Talk to our team