GRC on a Live System – Implementing the PDCA Cycle

Why did I build my own platform?

Throughout more than a dozen years of working in quality, information security, risk management, and compliance, I have observed that the biggest gap between theory and practice appears at the moment of implementation. That is why I created SecureHaveNET – my own platform that serves as an experimental proving ground where I can test and refine approaches related to GRC, ISO/IEC 27001, PDCA, and risk management in a real-world environment.

SecureHaveNET was born out of a simple need to test theory in practice. It is about testing my skills in various roles and, ultimately, documenting these experiences not only for myself but for others as well.

GRC in practice – or is it just an abstraction?

For many, GRC is just a collection of rules.

I feel it differently: for me, it is the operating system of my project.

Managing the domain and structure of SecureHaveNET was not limited to uploading a simple index.html file to a server. It was a choice of conscious hierarchy and architecture. In this context, GRC became for me a set of questions about purpose, risk, and compliance.

Governance: This is my vision. Does this name, this structure, and this skeletal framework of the site actually fulfill the goal of creating a substantive knowledge proving ground? A haven that not only develops me but also inspires and is useful to my readers.

Risk: This is the ability to anticipate what could destroy this vision – from architectural errors and performance issues to a lack of substantive content for the reader.

Compliance: This is the verification of whether what I implement is consistent with the established quality standards and my own expectations.

Only when I defined GRC in this way could I proceed to actual construction – and it was right here, in the process of constantly checking this consistency, that my PDCA-based approach was born. Below, I present how I have translated these assumptions into specific areas of risk and technical solutions.

PDCA in practice

One of the reasons this project proved so valuable was the opportunity to observe the PDCA cycle in action, where every phase is crucial.

Plan

In my assessment, one of the most frequently neglected elements of planning is requirements analysis and risk assessment. An idea alone is not yet a project; it must be translated into specific requirements, constraints, and expected outcomes.

Risk management begins with the very first decision

Building the platform was an exercise for me from the very beginning. Each design decision came with specific benefits, costs, and potential threats.

Therefore, risk management was present from the start as part of the planning stage. Not in the form of a formal register, but as a continuous process of identification, assessment, and decision-making.

Although I did not maintain a formal risk register, my decision-making process was very similar to the approach used in professional business projects. First, threat identification. Then, impact assessment. Finally, choosing the appropriate risk mitigation actions. Before selecting the final solution, I tested various options, analyzed pros and cons, and considered the long-term consequences of every decision.

In the case of SecureHaveNET, the planning phase included selecting the platform's technology and architecture, as well as defining requirements regarding security, performance, regulatory compliance, and ensuring an intuitive and comfortable experience for users.

Do

After the planning phase is completed, the actual implementation of the project begins. This is where theory meets practice.

During the development of SecureHaveNET, it often turned out that technically correct solutions did not always meet expectations regarding performance, ergonomics, or visual consistency.

Prototypes and testing various solution variants were also essential elements. Thanks to this, some flawed decisions were eliminated before the actual implementation began (though not all of them).

Therefore, the implementation did not consist solely of writing code. It also included testing different concepts, analyzing results, and continuously adjusting the project to the established goals.

Optimization: Performance vs. UX

Many optimizers fall into the trap of removing all interactions to gain milliseconds. I chose a compromise. I realized that the site should be not only fast but also useful. The results show that it is possible to reconcile these – while maintaining animations and dynamics, I achieved significant progress.

Conscious security (Supply Chain Security)

During development, I made the decision to abandon external libraries (CDN) in favor of local resources. In the era of supply chain attacks ("Trojan horse" in external code), I considered moving all scripts to my own server to be the only way to achieve full control. This approach forced better code organization but gave me peace of mind – if something doesn't work, the issue is mine, not the provider's.

Professionalism built on details: From general to specific

True professionalism does not end with a vision – it is realized in the details. My approach, based on top-down design, combines strategic frameworks with technical optimization. It is the sum of "invisible" decisions that builds the final effect.

• Security: Implementation of HTTPS, rigorous configuration of CSP (Content Security Policy), and protection against tabnabbing attacks (rel="noopener").
• Performance: LCP optimization from 6.2s to 0.7s through precise adjustment of the main thread (TBT) and resource formats.
• Semantics and Accessibility: Implementation of a clean HTML structure that improves indexing (SEO) and accessibility (A11y).
• Risk Management: Transparent communication of disclaimers and visual segregation, treated on par with technical safeguards.

The PDCA Paradox: Why I stopped chasing microns and seconds

As someone rooted in quality, I naturally strive for perfection. However, I quickly noticed that endless PDCA iterations can become a trap – leading to "project freeze" through analysis. I realized that it is scientifically proven: the constant pursuit of the ideal kills progress. My approach changed to a "small steps" technique: I implement a solution that is "good enough" (not ideal). I measure the results. If it requires improvement – I upgrade it. I accept the fact that there will always be something to improve if I have the time.

I realized that I am not chasing microns, but value. A completed project that works correctly is worth more than an ideal prototype that never saw the light of day.

Check (Audit)

For me, an audit is not just a formality, but primarily an opportunity for verification and learning (ISO/IEC 27001:2022, clause 9.2 Internal audit). Of course, one could outsource an external audit, but in this case, I decided on self-verification. In practice, this meant analyzing metrics such as loading time, number of requests, link security, as well as assessing compliance with requirements. Audit results — non-conformities and items for improvement — open the way to real improvement.

Both formal audit assessments (e.g., compliance classes) and ongoing process metrics serve as real tools that precisely indicate what needs improvement. (ISO/IEC 27001:2022, clause 9.1 Monitoring, measurement, analysis, and evaluation).

Scale explanation:

• 0–49: Critical (Requires intervention)
• 50–89: Needs optimization
• 90–100: Optimal

• Performance - Page loading speed and responsiveness (key for UX).
• Accessibility - Inclusivity and page adaptation for users with disabilities (WCAG).
• Best Practices - Code hygiene and technical security (e.g., HTTPS, lack of outdated libraries).
• SEO - Search engine visibility (site structure, indexing, meta-data).

In conclusion, the results confirm the effectiveness of the implemented optimizations. The performance growth (+24 points for desktop and +41 points for mobile) and SEO +8 points for both prove the validity of the project assumptions. Currently, technical stability and a high UX standard remain the top priority. The remaining areas for improvement have been included in the backlog and will be addressed in the next PDCA cycle.

Act

For me, every audit and metric is an entry point into the improvement process; both are essential and complement each other. If we do not know what needs improvement, we cannot develop.

I often hear: »why another audit if things were fine?«. For me, it's not nitpicking, but an opportunity for verification: is it safer, faster, better? An audit for the sake of an audit is a waste of time. Real value lies in the Act phase, where audit results are translated into concrete actions.

Key lessons

I have learned a lot, but I present the two most important lessons below.

The SecureHaveNET project confirmed an observation I see daily: success rarely depends on a single tool, technology, or procedure. Far more important is the decision-making process, the ability to identify risks, and consistency in continuous solution improvement.

Regardless of whether we are building a website, developing OT systems, implementing ISO/IEC 27001 requirements, or preparing an organization for a TISAX® audit, the fundamental principles remain unchanged:

Theory exists to be applied in practice, and every choice should be an informed calculation.

In my decision-making process, facts are crucial. I always compare options: what risks does solution A carry versus solution B? What is the cost of implementation, and — most importantly to me — is there a more creative path? I am an advocate for finding optimal solutions; I know that a higher cost does not always translate into greater security or better quality.

These lessons allow me to better understand organizational challenges. In this project, I faced the essence of GRC: how to balance the profit and loss statement with risk reduction, using limited technical resources.

Summary

I treat GRC as a map. Governance sets the direction and boundaries (frameworks), informing you where you are headed and which standards you must follow to maintain compliance and security.

In turn, the PDCA cycle is like both a compass and a lever. It is a mechanism used in daily work to get closer to the designated goal. Thanks to the Check and Act stages, PDCA allows for real-time course correction, verifying system performance, and implementing necessary optimizations.

The values of these areas complement each other – one without the other is insufficient. GRC without PDCA remains only a theory, while PDCA without GRC becomes wandering without a purpose.

Within just a few months, SecureHaveNET has transformed from a simple technical project into an environment enabling the practical testing of GRC, information security, risk analysis, and continuous improvement topics. Thanks to measurable KPIs, regular reviews, and the PDCA methodology, this project has become living proof of the effectiveness of the mechanisms I use in my daily professional work.

References and source documents

• ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements.
• ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls.