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 practical learning and experimentation platform 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 involves identifying applicable legal and contractual requirements and adopted rules, and checking whether they are met. I assess my own quality expectations separately as project criteria.

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.

Annex A mappings are indicative and relate to selected aspects of the project. They do not replace risk assessment, justification of control selection or verification of effectiveness.

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)

I host my own code and libraries locally to reduce dependence on external CDNs when the site loads. This does not remove risks associated with code provenance, updates or hosting configuration. The website still uses external services, including Google Analytics loaded after user consent. File location is one element of control, not a security guarantee.

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, configuration of CSP to restrict permitted resource sources (Content Security Policy), and protection against tabnabbing attacks (rel="noopener").
• Performance: Optimization of resources and page loading, assessed using the reports described in the Check section. LCP and TBT describe different aspects of performance; the results alone do not establish each change's contribution to improvement.
• 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. In my project, further refinements began to delay completion. I needed a criterion to distinguish necessary changes from continued polishing of details. 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.

Decision example: local resources and external services

Problem: dependence on external code providers during page loading. Decision: own scripts and libraries are hosted locally, while required external services remain separate dependencies. Verification: resource references and analytics bootstrap code show this separation; functional checks also require a browser. Limitation: library versions, service changes and hosting configuration still require oversight. A local file does not itself establish code security.

Check (Verification and self-assessment)

The Check phase included my analysis of automated Google PageSpeed Insights tests powered by Lighthouse. The results helped identify improvements and assess subsequent project iterations.

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

New measurement: 29 September 2026

Results for the homepage https://securehavenet.ovh/, desktop measured at 16:54 CEST, mobile at 16:59 CEST using Lighthouse 13.5.0. Scale: 0-100 points.

PageSpeed Insights - Desktop · PageSpeed Insights - Mobile

These are automated test scores for one URL, not confirmation of full WCAG compliance or a security audit of the entire website. The report contains no CrUX field data. Scores may vary between runs.

• 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).

The measurements show project progress: desktop performance increased from 39 to 100 points and mobile from 49 to 100 points. Historical results remain as a record of earlier iterations; differences in conditions and Lighthouse versions limit direct comparability. Further work includes maintaining results and manually reviewing areas beyond automated test coverage.

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.

I compare options by their risks, implementation costs and expected results. A more expensive solution does not necessarily provide better security or 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.

I use PDCA to plan changes, test them and review the results. The Check and Act stages help me decide what to keep and what to improve.

In this project, GRC helped establish direction, risks and requirements, while PDCA structured changes and evaluation of their effects. This describes my approach, not a condition for every project to succeed.

SecureHaveNET gives me a place to test technical changes alongside risk assessment and security requirements. I use indicators and regular reviews to assess the results and plan further improvements.

Ultimately, I am increasingly convinced that systems are meant to support people, and people create value. Technologies, processes, and standards are merely tools for this purpose.

Systems support people - people create value