Skip to main content

Pixel Bowl Studio

ISO/IEC 27001 Certified: Building Trust in Game QA
No Comments
Studio Journal / Information Security

Good games need trusted partners.

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?

01 / UNDERSTANDING THE STANDARD

A framework for managing information security.

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.

Confidentiality

Keeping information accessible only to the people authorised to use it.

Integrity

Maintaining information so it remains reliable and protected against inappropriate changes.

Availability

Making information accessible when authorised people need it for their work.

Continual improvement

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.

02 / THE REALITY OF GAME PRODUCTION

The build is only part of the picture.

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.

Examples of information to consider when planning a game QA engagement.
Project materialWhy it mattersWhat to agree
Unreleased builds and assetsMay contain confidential gameplay, art or story content.Who can access them and where they may be stored.
Bug reports and capturesCan expose the same content as the build itself.Approved reporting tools, recipients and attachment handling.
Test accounts and credentialsMay provide access to project environments.Account ownership, permissions and access removal.
Logs and diagnostic filesMay include identifiers or details about internal systems.Which evidence is needed and how it should be shared.
Roadmaps and release plansCan 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.

03 / OUR CERTIFICATION JOURNEY

Building the system behind the work.

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.

Start with an honest assessment.

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.

Make responsibilities part of daily work.

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.

Review, audit and improve.

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.

04 / FROM CERTIFICATION TO COLLABORATION

What this means for studios and publishers.

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.

Define access around the work.

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.

Agree how findings travel.

Choose the reporting channels and audiences for defects, captures and logs. A clear process helps useful evidence reach the right people without unnecessary copying.

Plan for changes.

Team changes, new platforms and additional tools can alter the information involved. Treat those changes as a reason to revisit the original arrangements.

Include the handover.

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.

05 / LOOKING AHEAD

New tools. The same need for care.

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.

Let’s talk about your project

Start with the game. Include the requirements.

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