Who should own/handle/monitor the risk after product increment developed?

I don't think that Scrum Master is ever the right answer. Depending on the risk, it could be either the Product Owner or the Developers. Specifically for risks around regulatory requirements and governance, I'd look primarily toward the Product Owner, since failure to identify and mitigate these risks would limit "the value of the product resulting from the work of the Scrum Team", which is something the Product Owner is accountable for maximizing.

I agree with @Thomas.  The Scrum Masters realm of responsibility is to ensure that everyone understand and appreciates the Scrum framework. It is not to manage the project or product delivery.  The type of issues you mentioned should fall to the Product Owner and Developers.  The Product Owner should make the governance and regulatory requirements visible and transparent to the entire organization as part of the Product Backlog Item.  Developers should be aware of the requirements and build the solution with them in mind.  I would also suggest that the governance and regulatory requirements should be incorporated into the Definition of Done if they apply to all the work that the Scrum Team does. 

Outside always generically said scrum master should track and report the risks. 

Why? Who would they report to? In Scrum, the people doing the work ought to monitor and manage their own progress and the risks to it. That's the kind of behaviour a Scrum Master should try to cultivate.

However, I would like to ask if the product incremental already developed and tested. There are risk due to governance or regulatory requirement for the product to release / mass launch. Who should be the one own/track/monitor the risk?

It sounds as though the Increment is not Done. It may be have been developed and tested to some degree, but it is not yet of usable quality because it fails to meet certain regulatory requirements.

In Scrum the Developers are accountable for quality assurance and for ensuring that work is Done and of an immediately usable standard.

You mean developed or released to customers and end users?

 Because its different scenarios

If it is released, then you come to the key question to whole Agile/Scrum business

HOW TO COLLECT AND CONTROL CUSTOMERS FEEDBACK FAST AND IN MOST EFFICIENT WAY?

Go figure...

Techniques vary and depend on your particular domain of business

But in overall its Product owner who should be an ultimate destination of the feedback(which can be collected by developers, survey, PR team, management, google reviews of your business, walking on the street and asking opinions, whatever), because tis feedback should be reflected in Product backlog in a first place.

You mean developed or released to customers and end users?

 Because its different scenarios

If it is released, then you come to the key question to whole Agile/Scrum business

HOW TO COLLECT AND CONTROL CUSTOMERS FEEDBACK FAST AND IN MOST EFFICIENT WAY?

Go figure...

Techniques vary and depend on your particular domain of business

But in overall its Product owner who should be an ultimate destination of the feedback(which can be collected by developers, survey, PR team, management, google reviews of your business, walking on the street and asking opinions, whatever), because tis feedback should be reflected in Product backlog in a first place.

Thank you very much for the opinion. Sorry for the unclear statement. To add on. The product already delivered (passed all the testing as well), only haven’t launch for customer to use.

Regulatory requirement only meaning those company policy. As like, you need to pass certain committee within the organization to ensure you new increment met the company regulatory or government regulatory requirement only. Nothing to do in technical requirement (all technical things completed already). However, only with such approval from other department, we can business launch our new increment to customer.

Sadly to say still a lot people still expect Scrum Master to take care such non scrum team related exercise. Moreover how I explain project management is different from scrum and sprint, or scrum master job scope. 



I also totally agree we should not use monitoring as scrum team should be self motivated. Plus as a scrum master, my believe is if the risk is any impediments affecting the sprint or the team, I always come out and help to remove /resolve them to ensure the efficiency and effectiveness of the scrum team and sprint.

That’s why I would like to seek for other experts help to share your view. Truly appreciate all your sharing. At least I can share with them so point of view for other scrum professionals. 

Opinion: In the nutshell the administrative body who is supervising the release of the product should give product owner the authority to decide when to release the product without further approval from the supervisors

If some legal framework is necessary they should do be ready to prepare it.

Without this element the whole framework of Scrum you are trying to follow through is missing the important element(respect for the decisions of PO within the organization).

Alternatively having the necessary permissions to release the increment to the market can be added to Definition of Done, so the Increment will be Done only when all necessary documentation will be obtained. 

If necessary Product owner can hire an assistant (PO will be still solely responsible for the Product, but he can hire the assistant) to handle the administrative aspects or such person can be even included in the team as a developer. Please keep in mind that "developer" isn't necessarily an engineer, anyone who helps the increment of valuable product can be a "developer" in a Scrum team

In Scrum, the goal is to provide at least one usable increment of value to the stakeholder in each Sprint.  But stakeholder does not have to mean customer.  In your case, the stakeholder that you release the usable increment of value to would be your internal boards that regulate the actual release of the product.  

The Scrum Guide is somewhat ambiguous on what it means by "release" and "stakeholder". I believe that is on purpose because of such situations as yours.  

My suggestion is that your Product Owner should be the one that monitors those final steps required for the ultimate customer delivery.  They are the ones responsible for the relationships with the stakeholders and for ensuring that the Developers are working on the right things.  The Developers have completed their part of the work in their Sprint.  The Scrum Master is doing their part by ensuring that the organization understands and respects the Scrum framework and that the Scrum Team is able to self-organize on the work that is needed to improve the Product. 

Your challenge will be helping the organization understand that your team's stakeholders are internal and not the external customers.

It seems like you're trying to use Scrum - a framework that is based on the values and principles of Agile Software Development - in an environment that is still thinking sequentially. There should be no need to get committee approvals as a gate late in development to release the work to customers. Instead, consider the Agile principle of developers working with the business on a regular basis throughout the effort. Scrum realizes this through the role of the Product Owner as the empowered and accountable representative of all stakeholders and the Sprint Review to bring key stakeholders and the Scrum Team together at regular intervals. If the people on these committees are regularly communicating with the Product Owner and actively participating in Sprint Reviews, there should be no need for additional gates in the flow of work and value.

The Scrum Master is accountable for removing impediments (and a gated process to delivery is an impediment to value delivery) and for coaching all stakeholders in empirical product/service development, agility, and adoption of the Scrum framework. This seems like an opportunity to help the organization increase their agility by finding ways to remove gates and delays in the delivery process.